I don't see this offering much over performing a diff and committing the
specific portions of your working copy which make up a change set. The
primary benefit seems to be the ability to commit directory props
without committing modified files from that directory, at the cost of
completely losing those directory props -- all props, for that matter --
when the patch file is re-applied.
What am I missing?
On Mon, 2005-06-13 at 08:36 -0700, ser@germane-software.com wrote:
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 13 18:25:37 2005