[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Block-level commits

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2005-06-14 00:10:27 CEST

On Mon, 2005-06-13 at 12:02 -0700, ser@germane-software.com wrote:
>> 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.
>
>How do you "commit specific portions of your working copy"? Just to
>clarify, I'm talking about a mechanism which allows you to commit not only
>whole files, but just parts of a file.

Thanks for the clarification; this is a key distinction. I was
referring to on a file-by-file basis (specified explicitly on the
command-line). More on this below.

...
>A use case example for the problem that I'm trying to solve is:
>
>I'm working on some new feature. Along the way, I stumble across some
>previously undiscovered bug in my code -- something minor, perhaps a typo
>-- so I fix them. I'd like to commit *just* those changes, but I've also
>been changing the file in other places.

Thanks for providing a use case, always helpful.

>The only ways that I know of to do this in SVN is to break out of what I'm
>doing, check out another copy and make the changes there; or try to
>remember what I need to change and implement it after I'm done with what
>I'm doing. Both of these methods interrupts my workflow.

Right. Or, create a patch containing your local changes, revert the
files which contain changes from separate change sets, cherry-pick the
portions of the patch relevant to your first commit, and possibly edit
them out of the patch for subsequent application back to your previous
state. Which I gather is what your script automates, to an extent.

Personally, I keep around multiple working copies on a couple different
machines. Which approach I use depends on the scope of the changes I
want to commit, and the state of my working copies.

Using traditional patch, how do you deal with changes from multiple
change sets within a given hunk? patch's inability to gracefully deal
with this is one of the factors which drives me to use multiple working
copies (build/run/test state of the code being the other primary
factor).

>Just to head off a cost/value discussion: I'm not particularly
>interested
>in trying to convince anybody that block-level commits AKA partial commits
>AKA cherry picked commits is a useful feature; I've already decided that
>it is, and having once wielded the power of block-level commits in darcs,
>I'm unwilling to do without them. My only interest, then, is gaining this
>functionality in SVN, and possibly providing it to others who might be
>interested in it.

Without a doubt, "working copy changeset management" a very useful
feature! I would definitely prefer to reduce the number of working
copies I need to keep around to a minimum.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 14 00:12:46 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.