Ben Collins-Sussman wrote:
>
> On Oct 13, 2004, at 5:06 PM, Mark Phippard wrote:
>
>>> The goal here is that the "non VC" user never ever sees a Conflict. We
>>> don't want non-techies to see a "C" next to a file, to have to
>>> understand the 3 fulltexts, or the 'svn resolved' command. Go look at
>>> the 'hijack' section of the UI document to understand this motivation.
>>
>>
>> I understood the motivation, I just didn't understand how the proposal
>> solved it. Also, what I am mainly interested in is that if someone uses
>> this feature with say a .c file, that I think it ought to work the way it
>> currently does. If the file is not mergeable, then I have no
>> objection to
>> making it work differently. Although, personally, I think it should
>> raise
>> the conflict and require you to make it resolved.
>>
>
> 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?
Frank Compagner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 02:27:30 2004