Ping. Does anyone have any ideas about this?
This is the "problem":
$ svn diff -r18353 www/links.html
svn: Unable to find repository location for 'www/links.html' in revision 18353
That's because there were a couple of commits in between Karl preparing
the commit that became r18355 (copying project_links.html to links.html),
and his committing it. None of the intervening commits modified
www/project_links.html, so the version of www/project_links.html at
r18353 is identical to that at r18349, the source of the copy operation.
I think this is unreasonably restrictive. Am I missing something?
Regards,
Malcolm
----- Forwarded message from Malcolm Rowe <malcolm-svn-dev@farside.org.uk> -----
From: Malcolm Rowe <malcolm-svn-dev@farside.org.uk>
To: Simon Large <simon@skirridsystems.co.uk>
Cc: Subversion Dev List <dev@subversion.tigris.org>,
Michael Pilato <cmpilato@collab.net>,
Karl Fogel <kfogel@collab.net>
Subject: Re: Cannot diff after file rename
Date: Fri, 10 Feb 2006 13:45:28 +0000
(Karl, Mike: any ideas on the below? It looks like the fallout from the
1.3.x history-tracing changes may be unnecessarily penalising our users).
On Thu, Feb 09, 2006 at 10:57:23PM +0000, Simon Large wrote:
> >>Malcolm Rowe wrote:
> >>> r1 r2 r3
> >>>TestB.txt --> TestB.txt > TestB-New.txt
> >>> \____________________/
> >>>
> >Also, other people's commits won't affect this. Your working copy doesn't
> >have to be completely up to date, just enough that you don't orphan the
> >file like in the diagram above.
>
> I just tried this: update after r1, commit r2 from a different WC,
> rename and commit in r3. Behaviour is the same - as you would expect
> from your diagram. And the commit doesn't even have to be in the same
> folder, just in the same repository. Any bump in the global revision
> number between copy and commit will trigger this behaviour, no?
>
Ouch. Yes, you're right. I was thinking the answer was "no", but this is
precisely the situation you're demonstrating in your reproduction recipe.
Sorry for being thick. (Updated reproduction recipe attached, which
should make it even clearer).
Yes, this is quite bad. How's the poor user supposed to race aagainst
everyone else's commits to make sure that they copy or rename the file
while it's still at HEAD?
While this is technically correct, I think we need to re-consider the
changes made for issue #1970 in light of this. It'd be fair enough if
(in the diagram above) r2 had changed the file in question's contents,
but since it didn't, we should really allow the user to diff between
the two revisions, I think.
That's probably beyond me though. cc:ing some likely suspects, and I've
added some notes to the issue tracker.
Regards,
Malcolm
# Reproduction recipe for issue #2496
rm -rf repo/ wc/ wc2/
svnadmin create repo
svn co file://`pwd`/repo wc
echo foo > wc/x
svn add wc/x
svn ci -m log_r1 wc
# We now rename 'x' to 'y'
svn mv wc/x wc/y
# Before we can commit, someone else commits something entirely unrelated
svn co file://`pwd`/repo wc2
echo foo > wc2/theta
svn add wc2/theta
svn ci -m log_r2 wc2
# Commit our rename
svn ci -m log_r3 wc
# Because 'y' was copied-from x@r1, we can't trace history back
# to r2, even though the file wasn't changed in that revision.
# "Hmm, has 'y' changed since r2?"
svn diff wc/y -r2
# svn: Unable to find repository location for 'wc/y' in revision 2
# Because the graph looks like this:
# r1 r2 r3
# x --> x > y
# \_______/
#
# But how is our poor user supposed to prevent that?
----- End forwarded message -----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 13:02:57 2006