DISQUS

Jason Skicewicz · 7 months ago

This is a very interesting idea, and is very similar to an idea I had at one point that had to do with carving up the useful parts of the web, and attaching notes to blocks of web content. Its similar in that it is carving up the web at a finer granularity than bookmarks, which is what inline SCM is doing for source control. I think the usefulness would far outweigh how tedious it may become, and would encourage smaller commits, which is useful in its own right. I personally, check the diff on every file before I commit code to the repository to 1) come up with a descriptive commit message, and 2) to make sure I did not leave any debug code in what I am about to commit. So this whole process of looking at every block of changed code, would work extremely well in my workflow since I do it anyway.

I thought I would point out that your example is not exactly valid, although it is the way that many teams work. In a team that is following good process, all new features are developed in an entirely different branch, and are pulled in to your release branch as they are finalized / wanted / requested by biz. This way, the main branch, which is usually the trunk, only contains bug fixes and any approved features that were pulled in (nothing is developed in the main branch). I think what happened to the project that you are referencing, is that new features were developed in the main release branch. This should never be the case. The reason this happened, is because it was felt that these features would never be stripped out of the product, and would be present in the next release. A very bad assumption. This idea is very interesting because no teams (or very few) follow good version control practice. I mean, just take a look at how useful commit messages are on most projects.

In any case, this is a very good idea. One that I would love to help you build out =). You could easily build this on top of subversion or git without rewriting anything by essentially creating a markup language in the commit message itself. Sort of like the way InterTrac does it.

Guest · 6 months ago

Interactive rebasing in git solves your problem.