You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Quinlan <qu...@pathname.com> on 2004/02/15 08:36:06 UTC
svn update/diff handles renames confusingly
If a working copy of a file has been modified locally and moved in the
repository, the behavior of svn when updating the tree (to HEAD) makes
no sense and is at best confusing.
First, you do the update:
$ svn update
[bunch of normally updated files]
svn: Won't delete locally modified file 'old_name_of_file'
The state of the tree is then bizarre:
1. new_name_of_file and old_name_of_file both exist
2. new_name_of_file and old_name_of_file are neither versioned nor
exported
After some confusion, I just copied the working copy elsewhere, updated
the tree, and tried the two "obvious" things:
1. diff the working copy of the file under the new name against an old
revision and you get the entire file back in the diff -- because the
file doesn't exist in the old revision (of course)
2. diff the working copy of the file under the old name and you get back
"svn: 'old_name_of_file' is not under version control"
The only way I could get a simple diff to work was to do the diff while
the tree is in the bizarre intermediate state where both files exist,
but this is entirely non-obvious from the original warning message. I
didn't actually figure this out until a few minutes after I had given up
and updated my entire tree to the old revision so I could do the diff
before the update (so I suppose I figured out two ways, but one is a
very small window and the second was very non-optimal).
How do you diff a working copy of a file against a version of the file
prior to the rename?
Also, why doesn't "svn update" handle renames? After this and previous
experiences, I now feel the need to warn other developers when I'm about
to rename a file.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Sander Striker <st...@apache.org>.
On Sun, 2004-02-15 at 21:52, kfogel@collab.net wrote:
> Daniel Quinlan <qu...@pathname.com> writes:
> > kfogel <kf...@collab.net> writes:
> > > 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?
> >
> > Sure. I spent a long time with Ben Reser on IRC last night as well and
> > he was able to reproduce it, although his take on the problem was
> > slightly different than mine.
> >
> > After some consideration, my problem seems to boil down to:
> >
> > - svn diff doesn't work across renames
> > - svn update doesn't handle renames at all
> > - svn update conflict resolution for renames is bizarre and confusing
> >
> > Do you guys have a test SVN repository I can use for this?
>
> The second point above is still very surprising to me.
>
> Are you unable to create a local repository yourself? (How did you
> first encounter this problem?)
>
> Sorry, I don't mean to be obstructionist, but the power of this list
> lies in its ability to distribute work. I'd like to avoid providing
> repositories for bug reproductions, since there's non-trivial overhead
> in creating it, making it accessible to you, and protecting it so it's
> not a security risk. If you can't make a repository of your own, just
> post your recipe untested and we'll work out any kinks here when we
> run it. It may be that on seeing the recipe, some subtlety will
> become obvious.
Dan can use the ASF test repository which he has access to.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> Daniel Quinlan <qu...@pathname.com> writes:
>>
>> After some consideration, my problem seems to boil down to:
>>
>> - svn diff doesn't work across renames
>> - svn update doesn't handle renames at all
>> - svn update conflict resolution for renames is bizarre and confusing
>>
>> Do you guys have a test SVN repository I can use for this?
>
> The second point above is still very surprising to me.
Update doesn't attempt to move the local file, it's simply an add and
a delete. That means that it doesn't work well with local
modifications
$ svnadmin create repo
$ svn import Makefile file://`pwd`/repo/Makefile -m ""
$ svn mv file://`pwd`/repo/Makefile file://`pwd`/repo/Makefile2 -m ""
$ svn co -r1 file://`pwd`/repo wc
$ echo xx >> wc/Makefile
$ svn up wc
A wc/Makefile2
../svn/subversion/libsvn_wc/update_editor.c:823: (apr_err=155000)
svn: Won't delete locally modified file 'Makefile'
$ svn st -v wc
! 2 1 pm wc
2 2 pm wc/Makefile2
M 1 1 pm wc/Makefile
The update stops at the local mod and leaves the working copy
incomplete.
We could add some sort of move heuristics to update, i.e. attempt to
detect moves as a copy-with-history plus a delete. Or perhaps every
copy-with-history should do a copy in the working copy if the source
is available. I have my doubts about how well heuristics could be
made to work, I'd much prefer a proper atomic move. And a new
libsvn_wc.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Daniel Quinlan <qu...@pathname.com>.
C Michael Pilato <cm...@collab.net> writes:
> So if you have a rename as a local mod, and someone else changes the
> file you renamed
This is not that case at all. The rename is already in the repository,
and the modified working copy is against the old name of the file. The
difficulty is when you update your tree and inherit the rename for a
file you've modified locally.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> > After some consideration, my problem seems to boil down to:
> >
> > - svn diff doesn't work across renames
> > - svn update doesn't handle renames at all
> > - svn update conflict resolution for renames is bizarre and confusing
> >
> > Do you guys have a test SVN repository I can use for this?
>
> The second point above is still very surprising to me.
Why is it surprising? A rename in Subversion is a "copy"
(add-with-history) and a "delete". While the new "copy" destination
tracks its source (as "copyfrom-path" and "copyfrom-rev" in the
entries file), the "delete" entry doesn't point to the new
destination. So if you have a rename as a local mod, and someone else
changes the file you renamed, "svn update" doesn't have the ability to
see that it should apply the diffs coming down the wire not to the
schedule-deleted thing, but to the schedule-add-with-history other
thing. We've talked in the past about solving this (and similar
complaints) simply by storing forward pointers in the "delete" half of
the local rename operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by kf...@collab.net.
Daniel Quinlan <qu...@pathname.com> writes:
> kfogel <kf...@collab.net> writes:
> > 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?
>
> Sure. I spent a long time with Ben Reser on IRC last night as well and
> he was able to reproduce it, although his take on the problem was
> slightly different than mine.
>
> After some consideration, my problem seems to boil down to:
>
> - svn diff doesn't work across renames
> - svn update doesn't handle renames at all
> - svn update conflict resolution for renames is bizarre and confusing
>
> Do you guys have a test SVN repository I can use for this?
The second point above is still very surprising to me.
Are you unable to create a local repository yourself? (How did you
first encounter this problem?)
Sorry, I don't mean to be obstructionist, but the power of this list
lies in its ability to distribute work. I'd like to avoid providing
repositories for bug reproductions, since there's non-trivial overhead
in creating it, making it accessible to you, and protecting it so it's
not a security risk. If you can't make a repository of your own, just
post your recipe untested and we'll work out any kinks here when we
run it. It may be that on seeing the recipe, some subtlety will
become obvious.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Daniel Quinlan <qu...@pathname.com>.
kfogel <kf...@collab.net> writes:
> 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?
Sure. I spent a long time with Ben Reser on IRC last night as well and
he was able to reproduce it, although his take on the problem was
slightly different than mine.
After some consideration, my problem seems to boil down to:
- svn diff doesn't work across renames
- svn update doesn't handle renames at all
- svn update conflict resolution for renames is bizarre and confusing
Do you guys have a test SVN repository I can use for this?
- Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Ben Reser <be...@reser.org>.
On Tue, Feb 17, 2004 at 10:13:12AM -0600, Ben Collins-Sussman wrote:
> "Making diff follow copy-history" was a big issue that almost made the
> 1.0 cut, but a few months back we decided it would probably be the first
> thing to go to 1.1. Nobody should be surprised by this shortcoming;
> it's a well known wart that's been discussed to death. It's documented
> in the book, and I even mentioned it as an annoyance in my anti-fud
> essay.
I guess I just didn't realize how annoying it was until I saw the
example of the update issue...
--
Ben Reser <be...@reser.org>
http://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
Re: svn update/diff handles renames confusingly
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-02-16 at 00:33, Ben Reser wrote:
> On Sun, Feb 15, 2004 at 11:23:24PM -0500, Greg Hudson wrote:
> > I agree that it's a big wart, but I don't think it should delay 1.0. It
> > can most likely be fixed in 1.1 (with compatible API extensions at
> > most), and frankly, we know that 1.0 isn't going to be perfect for all
> > projects. The fix for this problem isn't simple (it ties into "we don't
> > have real rename tracking" and "svn_repos_dir_delta is highly
> > path-oriented, not node-oriented"), so we'd have to delay 1.0 for months
> > to fix it.
>
> Wow, months? I guess we'll have to live with it for a while, I
> certainly didn't realize it was going to be that complicated to fix.
> But I still think accelerating the rate at which we do minors might be
> worthwhile.
"Making diff follow copy-history" was a big issue that almost made the
1.0 cut, but a few months back we decided it would probably be the first
thing to go to 1.1. Nobody should be surprised by this shortcoming;
it's a well known wart that's been discussed to death. It's documented
in the book, and I even mentioned it as an annoyance in my anti-fud
essay.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Ben Reser <be...@reser.org>.
On Sun, Feb 15, 2004 at 11:23:24PM -0500, Greg Hudson wrote:
> I agree that it's a big wart, but I don't think it should delay 1.0. It
> can most likely be fixed in 1.1 (with compatible API extensions at
> most), and frankly, we know that 1.0 isn't going to be perfect for all
> projects. The fix for this problem isn't simple (it ties into "we don't
> have real rename tracking" and "svn_repos_dir_delta is highly
> path-oriented, not node-oriented"), so we'd have to delay 1.0 for months
> to fix it.
Wow, months? I guess we'll have to live with it for a while, I
certainly didn't realize it was going to be that complicated to fix.
But I still think accelerating the rate at which we do minors might be
worthwhile.
--
Ben Reser <be...@reser.org>
http://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
Re: svn update/diff handles renames confusingly
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-02-15 at 22:16, Ben Reser wrote:
> 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.
I agree that it's a big wart, but I don't think it should delay 1.0. It
can most likely be fixed in 1.1 (with compatible API extensions at
most), and frankly, we know that 1.0 isn't going to be perfect for all
projects. The fix for this problem isn't simple (it ties into "we don't
have real rename tracking" and "svn_repos_dir_delta is highly
path-oriented, not node-oriented"), so we'd have to delay 1.0 for months
to fix it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn update/diff handles renames confusingly
Posted by Ben Reser <be...@reser.org>.
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
https://svn.apache.org/repos/asf/incubator/spamassassin/trunk/rules/
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
or
svn:
'https://svn.apache.org/repos/asf/incubator/spamassassin/trunk/rules/70_testing.cf'
was not found in the repository at revision 6441
or
svn:
'https://svn.apache.org/repos/asf/incubator/spamassassin/trunk/rules/70_cvs_rules_under_test.cf'
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 <be...@reser.org>
http://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
Re: svn update/diff handles renames confusingly
Posted by kf...@collab.net.
Daniel Quinlan <qu...@pathname.com> writes:
> First, you do the update:
>
> $ svn update
> [bunch of normally updated files]
> svn: Won't delete locally modified file 'old_name_of_file'
>
> The state of the tree is then bizarre:
>
> 1. new_name_of_file and old_name_of_file both exist
> 2. new_name_of_file and old_name_of_file are neither versioned nor
> exported
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.
Thanks
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org