Hi all,
I have a couple of questions related to block level commits. I'll lay
them out in advance, so you can avoid reading this post if they don't
interest you.
1) Is anybody interested in what I'm doing?
2) What are the fringe cases that I'm missing?
3) Is there a better way of doing this?
One thing I really like about darcs is block level commits; so much so,
that when I'm going to be doing a lot of work on a project, I often switch
to darcs temporarily to manage the commits, and then export the patches to
Subversion. While this works, it is a bit tedious, so I hacked up a
script to act as an interface to 'svn ci' that lets me cherry-pick the
code that is going into a particular commit. Basically, I'm getting finer
granularity over my commits.
The way the script currently works, it first executes an 'svn diff',
passing to it any arguments it has been given. It parses the output and
deconstructs it into files and blocks, and then presents this information
to the user a block at a time, allowing them to choose or bypass
individual blocks or entire files. I've shamelessly copied the darcs
workflow, including the command set. The script relies on the 'svn' and
'patch' commands.
What I'm wondering about is if there's an obvious logical flaw to the
process that I've missed. Here's what happens:
1) svn diff
2) break apart the patches, choose which will be accepted.
a) Write the entire diff, as a backup
b) Construct a patch including all of the accepted blocks
c) Construct a patch including all of the rejected blocks
3) svn stat
a) Keep track of the Adds/Deletes
4) svn revert
5) Delete all Adds
6) Apply the accepted patches (which will re-created the Adds)
7) Re-add the accepted Adds, re-delete the accepted Deletes
8) Commit the changes
9) Apply the rejected patches
10) Re-add the rejected Adds, re-delete the accepted Deletes
There's heavy error checking throughout this entire process, and attempts
to clean up should anything fail. In particular, the commit is a
dangerous point because of conflicts. If the commit fails, I am left with
a choice of (a) reverting and patching from the entire original patch, or
(b) resolving conflicts and then resuming at #8.
The entire algorithm was rather simple and straightforward until Adds and
Deletes entered the picture; then it started to look hackey. Still, it
works, and my concern is with fringe cases, such as properties; I strongly
suspect that I'm reaching the limit of what I can do without either
hooking into the Subversion bindings or turning this little script into a
full application.
There are a number of directions that I can go with this, but only two
interest me. The first is to rewrite this using language bindings, and
the second is to hack the svn client itself to support block-level
commits. If it won't be accepted formally into the SVN code, or if I have
to maintain it, I won't be doing the second option.
I welcome any feedback on this.
--- SER
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 13 17:50:00 2005