Justin Erenkrantz wrote:
> --On Wednesday, October 13, 2004 5:10 PM -0400 Ben Collins-Sussman
> <sussman@collab.net> wrote:
>
>> I disagree. The ignorant user has already made their edits by hijacking
>> a read-only file: why are those edits shoehorned away into a backup file
>> when 'svn up' is run? If we did this, the user would just be copying the
>> backup file on top of the repos file anyway. If the user is forced to
>> choose between their own changes and someone else's, and merging isn't an
>> option, they'll almost always prefer their own.
Well, just from my own experience, the only time anybody ever resets the
read-only flag by hand (we're currently using a proprietary SCM for all
the unmergable stuff) is to quickly try some stuff out without having to
wait for the lock release. After playing around with it, the user will
typically do an update to reset his changes, and, when the lock has been
released, might try to (re-)apply the results of his experiments to the
new revision. These files are typically big, complicated and completely
unmergable, so the version created after resetting the read-only flag
cannot reasonably be used for a commit without destroying the changes by
the original holder of the lock. That said, the user will have to revert
his changes anyway when he tries to acquire the lock (whether this is
done automatically or as a separate update), so it probably doesn't
matter too much. Maybe an extra update switch (--revert?) would be a
good idea?
> But, what if svn:must-lock wasn't set? (Either on purpose or by
> accident.) There could still have been a conflict in the file. In that
> case, the .mine, .rXXXX, .rYYYY paradigm gets enforced anyway. This is
> what happens today if you try to collaboratively edit binary file
> formats (which we do already and why I look forward to 'svn lock'
> functionality). I would rather us be consistent in our approach if
> svn:must-lock was set as if it wasn't set by moving towards the .mine
> approach. -- justin
I'm not sure if you want to pay too much attention to scenarios such as
this, but yes, it would seem like a good fallback behaviour. You still
need to choose which version ends up as the WC file, though.
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:02:56 2004