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

Re: Commit a mixed revision working copy as new HEAD?

From: Zachary Pincus <zpincus_at_stanford.edu>
Date: 2005-02-25 00:05:05 CET

On Feb 24, 2005, at 2:04 PM, Ben Collins-Sussman wrote:
> The fact that's it's a binary file only means that the file can't be
> "contextually" patched. As long as you have no local modifications
> to your files, 'svn merge -rHEAD:X' will have no problem tweaking your
> working copy to look like revision X. Remember that under the hood,
> svn uses binary-diffs on everything.

You are correct that 'svn merge -rHEAD:X' works fine for whatever kind
of file. All I was pointing out was that 'svn merge -rY:X' is rarely
appropriate for binary files if Y != HEAD. (As in the quoted text
below.) This was in reference to several suggestions to the effect that
one should never try to revert a file wholesale, and should always just
use 'svn merge -rY:X' to back out bad changes one at a time.

>> That is, the only svn merge command that makes sense is "svn merge
>> -rHEAD:nnn Figure1.ai" or whatever, where nnn is the last good
>> version. But, despite several assertions to the contrary, a "backward
>> patch" like this with svn merge simply cannot back out of a file
>> deletion. (Go ahead, try it.)
> Huh? That's simply not true. Watch:

Interesting. You can use merge to back out a deletion of some set of
files within a directory, as in your example below. However, it's not
possible to use merge to back out of the deletion of a single file or
directory selectively. That is,
'svn merge -rHEAD:25 .'
works fine, and will back down all files in the directory to the state
at revision 25, as you showed. However, try:
'svn merge -rHEAD:25 svn_wc.h'
This time, merge will complain with the error:
svn: 'svn_wc.h' has no URL

Note that, 'svn update -r25 svn_wc.h' is able to properly retrieve the
file without complaint. Is this then a problem with svn merge? Or is
this behavior by design? I know that part of my difficulty here is that
I keep insisting on rolling back changes to individual files, while svn
is more organized around the idea of sets of files being changed
atomically... however, this mode makes most sense for the sort of
art-revisioning I'm trying to do.

Thanks for helping elucidate this issue!

Zach Pincus

> [sussman_at_BenBook:~/scratch]$ svn co file:///usr/local/svn/testrepos wc
> A wc/svn_error_codes.h
> A wc/svn_diff.h
> A wc/svn_fs.h
> A wc/svn_dav.h
> [...]
> A wc/svn_ra.h
> A wc/svn_opt.h
> Checked out revision 25.
> [sussman@BenBook:~/scratch]$ cd wc
> [sussman@BenBook:~/scratch/wc]$
> [sussman@BenBook:~/scratch/wc]$ svn rm svn_wc.h
> D svn_wc.h
> [sussman@BenBook:~/scratch/wc]$ svn commit -m "deleted svn_wc.h"
> Deleting svn_wc.h
> Committed revision 26.
> [sussman@BenBook:~/scratch/wc]$ svn update
> At revision 26.
> [sussman@BenBook:~/scratch/wc]$ svn merge -rHEAD:25 .
> A svn_wc.h
> [sussman@BenBook:~/scratch/wc]$ svn status
> A + svn_wc.h

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 25 00:07:37 2005

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

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