Ben Collins-Sussman wrote:
>
> On Oct 14, 2004, at 9:41 AM, Mark Phippard wrote:
>
>>
>> I just think that we cannot just wush away the conflict. The user needs
>> to know that they have created a conflict and they should review the
>> files
>> before committing there change.
>
>
> I'm suggesting that the UI be something like this:
>
> $ svn update hijacked-file.c
> WARNING: you have changed this file without locking it, which is bad!
> WARNING: a newer version of the file has been saved in
> 'hijacked-file-backup.c'
> WARNING: please examine the newer file before committing your own
> changes!
This sounds reasonable, but the last warning doesn't make much sense in
the context I'm thinking of. If the files are completely unmergeable and
"undiffable" (even by human eyes), examining the new file won't do you
much good (especially if you haven't got the common ancestor available).
The only thing you can do is choose which one to throw away.
Doing it this way actually favours the rule-breaker, making it much to
easy to discard the changes made by others who did play by the rules.
The UI spec says: "VC ystem should be effortless, transparent and
idiotproof". This solution certainly meets the first two criteria,
(though the second might be helped by providing the r4 copy), and fails
the last one. If it is this easy to discard other peoples changes, I can
easily see this becoming the number one cause of work going missing.
If you really want it to be effortless _and_ idiotproof, I still say
that the only right way is to do it this way:
$ svn update hijacked-file.c
WARNING: you have changed this file without locking it, which is bad!
WARNING: a newer version of the file has overwritten your changes,
which have been saved in 'hijacked-file-backup.c'
This way the VC system actively works against people trying to subvert
it (whether on purpose or by accident), and is much more idiotproof.
If this is too much of a departure from the way svn handles conflicts on
mergeable files, I would much prefer creating an actual conflict and
letting the fancy gui client which these people are no doubt using
assist the user in making the right choice.
> How is that "wushing away" the conflict? Isn't that enough information
> to make the user review the newer file?
>
> The alternative is:
>
> $ svn update hijacked-file.c
> C hijacked-file.c
>
> ### "huh? what does C mean?"
>
> $ svn ls
> hijacked-file.c
> hijacked-file.c.r4
> hijacked-file.c.r5
> hijacked-file.c.mine
Even if it is done this way, you still need to choose which version
hijacked-file.c is after the update; it has to be either .mine or .r5,
and for the same reasons given above, I would prefer it to be r5. Still,
as long as a conflict is generated, the gui client could offer
assistance in resolving it, so it wouldn't matter as much in this case.
Our current VC for non-mergeable files (AlienBrain) will notify the user
when in encounters a hijack and ask if the user wants to overwrite his
changes by the newer server version. If yes, everything is ok and the
user can try to acquire a lock and redo his changes. If no, the user
keeps his changes, but if he then wants to acquire the lock, he has to
select an extra option forcing the client to skip the update that it
always does before it hands out the lock. This certainly isn't an ideal
situation, but it works reasonably well, and makes it pretty hard to
lose changes accidentally. This is actually pretty close to what section
II.B.3. says about dealing with hijacks (though that still makes it, in
my opinion, too easy to throw away other people's work).
If the hijack scenario is treated as a regular conflict, a good gui
client should be able to interactively resolve conflicts in a way the
non-VC crowd can understand, while minimizing the chance of accidentally
throwing away changes. The gui client can then issue the svn resolved,
without the need for the user to even know it (or the extra files) exist.
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 17:49:49 2004