cmpilato@localhost.localdomain wrote on 10/14/2004 11:27:12 AM:
> 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.
How would we handle naming clashes if we used file extensions? In other
words, what if I actually had a file named index.mine.html? I assumed
that this was one of the reasons Subversion didn't use extensions in the
first place.
Would there be any value, especially in the hijack scenario, of using less
techy names, such as:
filename.mine.ext
filename.base.ext
filename.new/theirs/modified/conflict.ext
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 Thu Oct 14 17:36:33 2004