(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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
- text/plain attachment: repro
Received on Fri Feb 10 14:47:11 2006