On Wed, Dec 21, 2011 at 12:10:26PM -0800, Randon Spackman wrote:
> One of my common use cases for subversion is to want to split my changes into two separate commits. In the past, I would do the following:
>
>
> 1) Check out
>
> 2) Make changes
>
> 3) Realize that this should be more than one commit
>
> 4) Copy directory "MyCode" to "MyCode2"
>
> 5) Revert changes I don't want to commit yet from "MyCode2"
>
> 6) Commit "MyCode2"
>
> 7) Delete "MyCode2"
>
> 8) Update "MyCode"; already committed changes are merged and no longer appears as diffs.
>
> 9) Commit remaining changes in "MyCode"
>
> Unfortunately, this use case is defeated by the 1.7 changes to a single .svn dir. My current workarounds are as follows:
>
> 1) Copy the entire working copy (multiple GBs, waste of time), or
>
> 2) Do an "svn info" to get repo and revision, then check this out somewhere to obtain the necessary ".svn" folder which is then copied to "MyCode".
>
> Neither of these is very elegant. I'd like to see a new svn command
> such as "svn localize" (don't keep my terminology if it sucks) that
> would make the directory you specify its own independent working copy
> that can be copied and manipulated individually, and possibly a "svn
> delocalize" to reintegrate it. (Although this can be accomplished
> less effectively by simply deleting the ".svn" directory and doing an
> update.)
>
> Is there already a way to do this? Thoughts?
Others have already pointed out the 'detach.py' script you could use.
I'd like to add that 'svn patch' (new in 1.7) has been written with this
use case in mind. Whenever I realize I'd like to split up my changes into
more than one commit I use this approach.
Save the output of 'svn diff' to a file and apply it with 'svn patch' later.
This works for most types of changes. Be careful with copies (translated to
plain adds by 'svn patch') and mergeinfo changes (not applied by 'svn patch').
Any other changes to file content, structure or svn: properties are retained.
'svn patch' skips changes listed in the patch file which are already present
in the patch target, so most of the time saving the full diff to a patch file,
undoing some changes, comitting, and then applying the saved patch works fine
if all you want to do is commit a subset of your local changes.
If 'svn patch' runs into conflicts (e.g. because before commit you edited a
line saved away in the patch) it produces reject files. Cleaning up those
rejects manually can be tedious. But rejects can be avoided if you follow
this hint from 'svn help patch':
Hint: If the patch file was created with Subversion, it will contain
the number of a revision N the patch will cleanly apply to
(look for lines like '--- foo/bar.txt (revision N)').
To avoid rejects, first update to the revision N using
'svn update -r N', apply the patch, and then update back to the
HEAD revision. This way, conflicts can be resolved interactively.
Once you feel comfortable working with patches you can also do some
fixups by editing the patch file before applying it, throwing out or
tweaking individual changes ("hunks" in patch terms) of the patch.
E.g. sometimes I save two copies of the same patch and then edit both
copies to produce two distinct changesets. This works because 'svn patch'
is quite tolerant and tries its best to apply changes even if lines of
code have been moved around in the target or if the line offsets recorded
in the patch don't match anymore.
Of course, none of this comes very close to the convenience of a real commit
shelving feature (like 'git stash' already mentioned in this thread).
There is an open request on our tracker to implement commit shelving as a
first-class subcommand ('svn shelve' or 'svn stash'), see
http://subversion.tigris.org/issues/show_bug.cgi?id=3625
You might want to add yourself to the Cc list there to keep informed
about progress. AFAIK nobody is currently working on this though.
As usual, everyone is welcome to jump in and have a go at it :)
Received on 2011-12-22 13:32:12 CET