Ben Sewell <Ben.Sewell@ricardo.com> writes:
> >>> 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
> >>
> >> And so the natural response is, perhaps we could fix this problem in
> >> all cases, lock and merges alike. Any sane person can see the utility
> >> in preserving the one piece of data that an entire operating system
> >> uses to determine file types.
> >
> > More than one operating system.
>
> So as not to break the current behaviour for merge conflicts, could this
> behaviour be an option until v2.0? Perhaps as a "--preserve-extensions"
> option on relevant commands, or a client-side WC option (do these exist?!
> I'm new to svn, catching up as I can; currently using CVS; I'd put this in
> the option in the equivalent of .cvsrc file, if there is one).
That's a good idea, but then we'd have to maintain support for the new
--preserve-extensions flag after 2.0 (as a no-op). I don't believe we
are obligated to maintain the existing naming structure of this files.
Humans and scripts aren't supposed to be looking for conflict files
based on their knowledge of our naming scheme -- they should be
parsing the output of 'svn info' to see the names of any conflict
files.
---------------------------------------------------------------------
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:29:58 2004