[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: line ending summary: the "Breg Hudtherton Proposal"

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2001-12-13 22:42:15 CET

On Thu, 2001-12-13 at 16:34, Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > > 3b - The newline style of text-base is preserved, and the bits
> > > converted as they're committed. After the commit, the
> > > repository and text-base are in the same style they were
> > > before, and the working file is in the same style *it*
> > > was in before.
> >
> > That last clause worries me; it means the contents of the working file
> > after a commit may be different from the contents you'd get from a
> > checkout. I don't think we want to allow that state.
>
> ? No, I don't think so... the style you'd get after a checkout would
> normally be the same as they were before you did the commit (talking
> about the working file, now). I'm missing something...?

In the normal case, yes. But not all cases are normal, as you should be
aware as a programmer. :)

Mandy (who uses MacOS 9) creates a text file and checks it in. Since we
are in a 3b world, this condemns the file to have CR line endings in the
repository forevermore. Linus checks out the file; his working copy
gets LFs. He edits the file and, because he is obtuse, he inserts a CR
somewhere in the file. Unless we want to error out in that case, when
he checks in the file, the CR stays a CR and the LFs also become CRs.
If he were check out the file again, the CR he inserted would become an
LF. So we need to make sure that happens to the file after commit, or
we get a file which looks locally modified even though it was just
committed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.