news <news@sea.gmane.org> wrote on 10/13/2004 11:36:20 AM:
> Justin Erenkrantz wrote:
>
> > On Wed, Oct 13, 2004 at 10:06:27AM +0100, Ben Sewell wrote:
> >
> >>Just to add a potential comment from the Windows crowd; not preserving
> >>extensions breaks the windows auto-launching behaviour for documents.
In my
> >>situation, locked files are liable to be MS Excel files, for example;
if a
> >>non-techie attempts a check-in, and it fails, and none of the
remaining
> >
> >
> > Subversion already renames the extension when there is a merge
conflict to
> > '.mine', '.rXXXX', and '.rYYYY' I view the case of a lock race (?) to
be
> > essentially the same as a merge conflict from a user's perspective. --
justin
>
> Consisteny is alway nice, but there are definitely differences between a
> lock conflict and a merge conflict. Assuming that subversion will never
> attempt to merge a file with the svn:lock property, the current file
> version in the WC has to be either the local copy or the newly received
> server version.
>
> If we further assume that the svn client makes sure that all svn:lock
> files are read-only by default, and only become temporarily read-write
> when a lock has been acquired, lock conflicts are only possible when the
> user actively tries to work around it. I would therefore very much
> prefer the default behaviour to be to replace the WC version of the file
> with the the server version, while renaming the old (changed) local copy
> to .mine. This means that the .rNEWREV copy is no longer necessary.
> Also, the value of having the .rOLDREV is very questionable for
> unmergeable files, and might be costly (network trafic and/or binary
> diffs, I'm not sure how this is/would be implmented), especially as
> these unmergeable files will often be rather large (compared to plain
> text files). That would leave only the .mine version.
But isn't all of this assuming that users are only going to use this
feature for non-mergeable files? I think there will be a fairly large
number of users that will use this for all development, for a variety of
reasons. Subversion already has the mechanisms in place for automatically
merging files, tools like TortoiseMerge exist for manually resolving
conflicts, and Subversion is already smart enough to know what file types
it cannot attempt to merge.
Maybe this process could be improved, such as the way it uses file
extensions, but why create a second process? Why not have a single,
optimal, process?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 22:54:02 2004