[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: <ser_at_germane-software.com>
Date: 2005-06-13 21:02:54 CEST

> 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. If you're talking about manually
generating, editing, and applying the diffs against a clean copy, then my
method simply automates the process. And my method is entirely incapable
of handling property changes, and is probably broken in a dozen other ways
as well.

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.

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.

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.

--- 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 21:14:39 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.