On Oct 13, 2004, at 8:27 PM, Frank Compagner wrote:
>>>
>> I'll work to clarify the doc. What I'm proposing is this:
>> * user hijacks a read-only 'svn:needs-lock' file, edits it
>> * user tries to commit, gets error: "you need a lock!"
>> * user tries to lock, gets error: "you need to update!"
>> * user runs 'svn up':
>> A. if file is mergeable, merge it.
>> B. if file is unmergable, don't produce conflict, just back up
>> repos version.
>> So I *do* agree with you, regarding scenario (A) above. The deal is,
>> scenario (A) isn't very likely to happen. If the file were
>> mergeable, why did the admin put an 'svn:needs-lock' property on it?
>> ;-)
>
> But, in scenario (B), how is the user supposed to indicate that he
> _wants_ to revert to the repos version? After running 'svn up' as you
> suggest, he still won't be able acquire the lock, because his WC
> version isn't up-to-date. Or am I missing something here?
>
Suppose a user 'hijacks' revision 4 of a file, edits it. Meanwhile
somebody else locks r4, commits r5, then releases the lock.
The hijacking user fails to commit, then fails to lock, so eventually
runs 'svn up' as instructed. Their 'text-base' is updated to r5 (and a
copy of r5 is placed into a backup file) but the working file doesn't
absorb any r5 changes. It continues to be a modified version of r4.
When the user locks, the lock succeeds, because the working copy *does*
have r5 now: both the working-rev and text-base are r5. When the user
commits, they end up removing all of the r5 changes and adding their
own r4-based changes.
This is how conflicts already work right now. What's being left out is
the marking of the file as conflicted, the 3 text bases, and the need
to run 'svn resolved'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 15:28:31 2004