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

Re: svn update/diff handles renames confusingly

From: Ben Reser <ben_at_reser.org>
Date: 2004-02-16 04:16:36 CET

On Sun, Feb 15, 2004 at 01:44:03PM -0600, kfogel@collab.net wrote:
> This is very surprising. Can you give a concrete repro script, or at
> least describe the series of steps precisely, with real filenames &
> URLs and such?
> In (2), 'new_name_of_file' ought to be versioned, or
> else Subversion is insane... :-) A repro script would help remove any
> possible ambiguity from the prose description of events.

Here's a recipe to reproduce the problem that we used last night:
svn co -r 6441 https://svn.apache.org/repos/asf/incubator/spamassassin/trunk/rules/
cd rules
echo '#foo' >> 70_cvs_rules_under_test.cf
svn up

Which will give you:
svn: Won't delete locally modified file '70_cvs_rules_under_test.cf'
and an incomplete repo update.

My intial thought of how to work around this was:
svn up
(oops didn't work)
mv 70_cvs_rules_under_test.cf 70_testing.cf
svn up

Except after you do that you end up with a messed up file. Do it and
try svn diff, you'll see all kinds of extra changes that weren't made in
your wc.

So the real workaround for the user is to do the following (where the
file was renamed in r6607):
svn co -r 6441
cd rules
echo '#foo' >> 70_cvs_rules_under_test.cf
svn merge -r 6441:6606 70_cvs_rules_under_test.cf
(this produces a minor conflict which you have to resolve)
svn up
mv 70_cvs_rules_under_test.cf 70_testing.cf
svn merge -r 6607:HEAD 70_testing.cf
(again minor conflict)
svn up
(Which will unnecessarily restore 70_cvs_rules_under_test.cf but this
doesn't matter it deletes it againt right away).

Also note that svn diff and merge do not work across renames.
So you can't do:
svn diff -r 6441:HEAD 70_cvs_rules_under_test.cf
Even with --notice-ancestry it doesn't work.

You either get:
svn: '70_cvs_rules_under_test.cf' is not under version control
was not found in the repository at revision 6441
was not found in the repository at revision 6676

Depending on the syntax you try and use...

The current situation is not very acceptable. It means that if you have
a modified file in your wc that has been renamed you have to go digging
to figure out what rev it was renamed in and do a lot of mucking around
to deal with this.

If we could handle diffs/merges across renames we could do:
svn up
svn merge -r BASE:HEAD 70_cvs_rules_under_test.cf
mv 70_cvs_rules_under_test.cf 70_testing.cf
svn up

Ideally if we fix this when we do the svn up it would send us the diff
from BASE to HEAD and we could then merge those changes into the old
filename. Then mv the old filename to the new filename.

What good does having history do if we can't diff across the renames?
Handle updates across renames with modified working copies? Merge
across renames?

Frankly if we can't fix this in the 1.0.x branch without having to write
a new API we need to delay 1.0. If we don't fix it we'll have this ugly
"Renaming files creates headaches" wart to carry around for a long time.
Which is precisely one of the reasons we want to get away from CVS.

You could argue that this is an edge case. But I have to disagree, it's
only an edge case because CVS has trained us not to rename files. As
people use SVN and get used to renaming files being safe as far as
history goes, they're going to run into this again and again and again.
If we let that happen then SVN will have failed to achieve its charter,
providing a CVS like work flow without the poor implementation.

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 16 04:17:08 2004

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.