email@example.com 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
> > >>> user's perspective. -- justin
> > >>
> > >> And so the natural response is, perhaps we could fix this problem
> > >> all cases, lock and merges alike. Any sane person can see the
> > >> 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
> > behaviour be an option until v2.0? Perhaps as a
> > option on relevant commands, or a client-side WC option (do these
> > I'm new to svn, catching up as I can; currently using CVS; I'd put
> > 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
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
Would there be any value, especially in the hijack scenario, of using less
techy names, such as:
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Oct 14 17:36:33 2004