Annotated diffs?
February 25, 2008
Perhaps I’m completely alone in this, but I don’t always commit every single change I make when I make it. A recent project has me chasing down a series of nested problems, and when it’s finally ‘fixed’, I have numerous changes in files that don’t necessarily relate to each other. For example, in one file, making changes to two separate methods which affect different functionality leaves me with the dilemma of having to comment on both separate changes in one commit. Or, alternatively, having one commit with multiple files which would be better suited to having some portion of the commit message associated with one file.
Again, yes, I’m not doing things ‘correctly’. However, perhaps others have this problem. If so, maybe someone’s found an answer as well. Is there any way out there to do ‘annotated’ diffs, which have different comments which apply to different areas or files in the single commit? Maybe ‘annotated diff’ isn’t the best way to describe this situation?
Did you like this post? Buy me a hot chocolate!
Posted in Development, Ideas, Software
February 25th, 2008 at 6:48 pm
If you were using a good change control system, you could commit for each related change.
February 25th, 2008 at 7:47 pm
Not sure what you mean by that. Most of the issue is the way I do things, I’ll admit, but if I commit file X and it has two different changes in it, the entire file gets committed. Are you saying that I should be able to commit just the changes in lines 50-80, for example?
February 25th, 2008 at 8:46 pm
If you used for instance SVK (built on subversion), you could commit locally after each change (make one change, save, commit, make the other change, save, commit) and then if you see things are working the way you want, push those changes to the remote repository (it would show as two commits even you sent them at the same time).
February 26th, 2008 at 12:31 am
Perforce (commercial) allows for specific blocks of code in a file (and across multiple files I believe) to be committed atomically. As you can imagine, this feature hinges on fairly intelligent difference detection. So naturally Perforce has a really great visual diff util called P4Merge. I haven’t used it since 2001, but it was pretty good back then.
It seems quite possible to implement this function on top of a system like CVS. I imagine this as a GUI tool which would let you visially select a subset of the differences in a file. With some diff and patch magic, it could then checkout the repository version of the file and patch it with the chosen changes, then commit that patched file back to the repo. I would definitely have a use for a utility like this — I get myself into the same bind sometimes.
I could see the GUI getting fairly complicated if “partial” commits were desired across multiple file though. You’d end up with a multiple step commit session, building up a list of partials to apply to the repo en mass (within the same commit and with the same message).
February 26th, 2008 at 11:19 am
You are asking for features which are inherent in the new generation of SCM known as “distributed”
See any of git, mercurial, bazaar or others.
February 26th, 2008 at 11:56 am
The problem with what you’re asking, is there is no way you can have tested what you’re committing, before you commit it (and therefore potentially share it with others).
If its just ‘for yourself’ or a small change then maybe you could get away with it, but I’ve seen many cases were unintended side effects creep in.
And you still have the problem of 2 different changes affecting the *same* line……
February 27th, 2008 at 12:42 pm
You’re asking for “darcs record”, which prompts for each changed chunk of each file: “Commit this? The whole file from here on? Skip this file?”
Then, it collects all chunks into a changeset and commits it. And you can configure it to run a test command on that changeset.
February 27th, 2008 at 12:46 pm
Wow - thanks everyone for the feedback. Obviously it’s a problem that has solutions, but it also sounds like it’s not a problem everyone has, or sees, initially. I’ve been using cvs and svn for probably 7-8 years now (some vss before that) but haven’t put my finger on the idea that this was needed until recently (past 6 months or so).
I’ll know this is something to investigate on future projects.
March 8th, 2008 at 4:34 am
You might want to check out commit-patch. It currently supports cvs, hg and darcs but it should be easy to add support for your favorite vcs. We originally wrote it back in the CVS days to get around this exact problem. I find that now I can’t live without it!
http://porkrind.org/commit-patch/
March 8th, 2008 at 8:15 am
Thanks David - that looks pretty slick! Is there any possibility it would work with subversion?