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? ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 23:18:07 2004