You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2001/12/13 19:09:38 UTC
line ending summary: the "Breg Hudtherton Proposal"
Whew, that is one heck of a thread. :-) I'm really glad we had the
discussion, though; all the current proposals are improvements on what
we started with.
The two contenders appear to be Greg Hudson's and Bruce Atherton's
proposals. They actually have a lot in common, so below I'm going to
describe them as one proposal with a "variation" step, and our
remaining decision is which way to go in that variation.
Note that I have simplified them slightly, to reduce the number of
properties, but haven't changed anything fundamental (I think).
Here we go:
The Breg Hudtherton Proposal:
=============================
1. The property `svn:convert-line-endings' means convert line
endings to client native form.
For example, when this property is on, a LF file in a Windows
working copy would be LF in the repository, LF in text-base, and
CRLF in the working file. All client operations compensate as
necessary, including patch and diff; these are implementation
details. The point is that the default state (the state of
files when an svn operation is not going on) is as described
above.
In the same working copy, a CRLF file would be CRLF everywhere.
The "conversion" is a no-op, because the file is already in
local style.
(Note: don't care about the actual prop name and exact values,
those are implementation details.)
This property is unset by default.
2. There is no other property :-). In particular, no property says
what style the file has in the repository. It has whatever
style it was created with. If the client is doing newline
conversion at all, it does it based on what it sees in the file,
it doesn't need to be told what's in the file. If the file
appears to have mixed newline styles, we can either fold them
all to one way, or do no conversion. IMHO either way is
acceptable in such a case, see below.
3. This is the variation step:
3a - The exact bits of the working file are always sent to the
repository on commit, and the repository (and text-base)
updated accordingly. This means that alternating commits
from different platforms would flip-flop the line-ending
style in the HEAD; on the other hand, it guarantees that
EOL conversion will never change the data someone thought
they committed.
+or+
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.
If text-base appears to have mixed newlines, then
probably we should just commit exactly whatever was in
the working file (i.e., effectively making that the new
canonical form of the file in the repository).
Both variations require the modified-p test, etc, to be tweaked.
I currently lean mildly toward 3a, because of the safety guarantee,
and because the consequences of flip-flop in the repository are not so
bad. (See `Appendix A' below for why I claim this. :-) ).
Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
more to say, feel free.
-Karl
Appendix A: Why do I claim flip-flop is not so bad?
----------------------------------------------------
Think of all the ways you can access the repository. If you're
browsing it with a web browser, it can handle any newline style it
sees. If you're accessing it with a Subversion client, you'll get the
proper newline conversion anyway, so no problem there.
Only if you're accessing it with some other DAV client, well, then
yes, you'll get whatever random newline style was last stored, but
consider: if you can't handle that style, then there was a 50% chance
that you wouldn't have been able to handle the file anyway (because if
there were a reliable repository-wide style, there's no guarantee it
would have been suitable for your particular client platform anyway!).
In other words, there's always *someone* who will have to do newline
conversion, we can't avoid that. If a client isn't able to do that,
than some of the files in the repository are just going to be
problematic. We can't solve that.
And of course, for files for which there is only one appropriate
newline style, they will always have that style in the repository
(because Subversion clients will never change their style, because the
property won't be set), so they'll be okay whoever checks them out.
If you retrieve them with some dav client that doesn't honor the
property, and your platform's editor messes up the newlines, and you
commit, well, I don't see how any scheme can prevent that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> 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.
Let's keep in mind that none of these schemes condemn files to any
particular style in perpetuity. You can always reset them by
temporarily disabling the property (if no more convenient mechanism is
available, though one probably should be, but more on that after the
3a vs 3b stuff is done coming in).
> 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.
Ooooh, neat. Nice example, thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 16:34, Karl Fogel wrote:
> Greg Hudson <gh...@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
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@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...?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
+1 3a, but...
The way you've presented it, we would be handling .dsp files exactly as
Subversion handles them now, since we wouldn't be setting the conversion
property. Are we happy with that? I thought we were having some
problems, and wanted a way to force those files to have CRLF line
endings on checkout when someone checks them in with LF line endings.
On Thu, 2001-12-13 at 14:09, Karl Fogel wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
> more to say, feel free.
+1 3b
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: line ending summary: the "Breg Hudtherton Proposal"
Posted by Sander Striker <st...@apache.org>.
> Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
> more to say, feel free.
+1 3b (the Bruce scheme).
I think that everything has been said. Not everything has been
read (it's becoming too much now :).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 13, 2001 at 01:09:38PM -0600, Karl Fogel wrote:
>...
> 1. The property `svn:convert-line-endings' means convert line
> endings to client native form.
Per other discussion on the list, I think people have said there should be a
way to enforce a particular CRLF, LF, or CR style (because the file is the
input to an inflexible tool).
>...
> it doesn't need to be told what's in the file. If the file
> appears to have mixed newline styles, we can either fold them
> all to one way, or do no conversion. IMHO either way is
> acceptable in such a case, see below.
I believe a warning for a mixed style file is desirable, overridable with
--force. More specifically, if the file is marked with a specific type
(CRLF, LF, CR) and it has newlines that don't match that style, then a
warning appears.
[ this is a tough choice though; it may be that somebody has inserted some
commentary or description or whatever into a file with an explicitly
different line style; but I'd say that line ending conversion should just
be disabled in such a case ]
>...
> updated accordingly. This means that alternating commits
> from different platforms would flip-flop the line-ending
> style in the HEAD; on the other hand, it guarantees that
As discussed elsewhere, I think the flip-flop has big problems for us
because of our multiple access paths. CVS never had to deal with it because
it did not have an "official" mechanism for working with the repository
directly. Thus, they didn't have to "officially" support anything. We have a
mixed blessing here: we do have neato official access, but it also means
more support of more wonky things that people may do.
>...
> If text-base appears to have mixed newlines, then
> probably we should just commit exactly whatever was in
> the working file (i.e., effectively making that the new
> canonical form of the file in the repository).
To be redundant... Warning. Force.
>...
> Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
> more to say, feel free.
Not obvious yet? :-) +1 3b
>...
> Think of all the ways you can access the repository. If you're
> browsing it with a web browser, it can handle any newline style it
> sees.
By definition, HTTP User Agents are supposed to do this. Thankfully :-)
> If you're accessing it with a Subversion client, you'll get the
> proper newline conversion anyway, so no problem there.
Yup.
> Only if you're accessing it with some other DAV client, well, then
Or a program that binds to libsvn_fs ...
> yes, you'll get whatever random newline style was last stored, but
> consider: if you can't handle that style, then there was a 50% chance
> that you wouldn't have been able to handle the file anyway (because if
> there were a reliable repository-wide style, there's no guarantee it
> would have been suitable for your particular client platform anyway!).
If you are considering a specific file at a specific point in time: yes, it
will "randomly" be correct for your platform or not.
BUT! If you look at a file across points in time, it will be right, then
wrong, then right, then wrong... Even worse, the apparent differences
between files fetched over a period of time will appear to be "the entire
file". The *actual* changes in the file will be completely obscured because
it looks like the whole darned file changed.
> In other words, there's always *someone* who will have to do newline
> conversion, we can't avoid that. If a client isn't able to do that,
> than some of the files in the repository are just going to be
> problematic. We can't solve that.
True. But we can also provide some consistency over time to the files as
they reside in the repository.
> And of course, for files for which there is only one appropriate
> newline style, they will always have that style in the repository
> (because Subversion clients will never change their style, because the
> property won't be set), so they'll be okay whoever checks them out.
Per previous discussion, this is unworkable. I check out a CRLF file and
pull it into my text editor. My editor goes, "bleh. ugly file. let me just
fix this..." When that file goes back in, we should be ensuring the proper
newline format (IMO).
> If you retrieve them with some dav client that doesn't honor the
> property, and your platform's editor messes up the newlines, and you
> commit, well, I don't see how any scheme can prevent that.
Commit time is just a bit smarter about how to handle a specific newline
setting...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
"decent" editors (was: line ending summary: the "Breg Hudtherton Proposal")
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 13, 2001 at 02:17:10PM -0500, Kevin Pilch-Bisson wrote:
>>..
> +1 for 3a, since most decent editors won't switch all the line endings anyway,
> they will either preserve the same style, or preserve the same style except for
> added newlines.
I *really* wish people would stop talking about "decent editors" or "proper
tools" or whateverthehell.
People out there are NOT always going to use a decent editor. We better be
able to deal with that. And "deal with" means "not screw them over hard." We
really ought to be able to compensate for wackiness from the user.
Did they try to check in a .dsp with LF endings? [and it was marked for CRLF
endings only] Well, we *know* that it is wrong, so we really ought to do
something about it for them.
[ this reminds me of programs (e.g. parsers) that say "you're missing a
semicolon right <there>". well, thanks a lot Mr Program, why didn't you
just put it in there for me? you know it should be there ]
Anyways. I hope not to see the word "decent" again in this thread. The world
is messy. We should deal with it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Eh? You've been pushing for no newline translation at all. Why the
> sudden switch to "must have translated newlines in the repository?"
Neither of the proposed solutions will deliver no newline translation
at all. So, I consider it a choice between the lesser of two evils. ;-)
> (Remember, the case in question is only for when someone Unix checks out
> the file, gets CRLFs, and edits and commits it such that it gets saved
> with some or all line endings using bare LFs.)
...which I've personally been guilty of in the past (not with this
project, I don't think, but...)
While I'd *like* to keep Subversion clean of all that newline
conversion jazz, the more I think about trying to actually live life
in those circumstances, the more punished I feel. So, I agree to
throw theoretical purity to the wind, give up hoping that we can all
live in peace and multi-newline-style harmony, and agree to newline
conversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 14:35, cmpilato@collab.net wrote:
> > My scheme (as I presented it) solves this problem if you set
> > svn:newline-style to CRLF. The file is committed with LFs, but they are
> > translated back to CRLFs on checkout (as well as in the working copy
> > after commit, if you add in my subsequent revelation).
>
> Ouch. That means I can't always get the latest .dsp file via my
> trusty Web browser... -1.
Eh? You've been pushing for no newline translation at all. Why the
sudden switch to "must have translated newlines in the repository?"
(Remember, the case in question is only for when someone Unix checks out
the file, gets CRLFs, and edits and commits it such that it gets saved
with some or all line endings using bare LFs.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> My scheme (as I presented it) solves this problem if you set
> svn:newline-style to CRLF. The file is committed with LFs, but they are
> translated back to CRLFs on checkout (as well as in the working copy
> after commit, if you add in my subsequent revelation).
Ouch. That means I can't always get the latest .dsp file via my
trusty Web browser... -1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 14:23, Karl Fogel wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Not true. A .dsp file is created on windows, checked in. A unix developer
> > adds a file to the build, and so adds it to the .dsp file. Her (admittedly
> > stupid) editor either converts all the line endings, or adds the new lines with
> > LF style endings. We still need a CRLF, CR, LF, etc value for the property.
>
> Sorry, I should have said "I don't see how either of these two schemes
> can prevent that". Yes, this scenario can happen, but...
My scheme (as I presented it) solves this problem if you set
svn:newline-style to CRLF. The file is committed with LFs, but they are
translated back to CRLFs on checkout (as well as in the working copy
after commit, if you add in my subsequent revelation).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: line ending summary: the "Breg Hudtherton Proposal"
Posted by Sander Striker <st...@apache.org>.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 13 December 2001 20:24
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Not true. A .dsp file is created on windows, checked in. A unix developer
> > adds a file to the build, and so adds it to the .dsp file. Her (admittedly
> > stupid) editor either converts all the line endings, or adds the new lines with
> > LF style endings. We still need a CRLF, CR, LF, etc value for the property.
>
> Sorry, I should have said "I don't see how either of these two schemes
> can prevent that". Yes, this scenario can happen, but...
>
> If the property has a value like this, how does Subversion behave when
> the given value completely disagrees with the actual line endings in
> text-base?
Then there will be exactly one flip. The client converts (a copy of) the
wc file to the eol type in the property. It then does the diff with
the text base and that is use to commit. In other words: next time
the text base and the eol property _will_ agree.
> -K
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> Not true. A .dsp file is created on windows, checked in. A unix developer
> adds a file to the build, and so adds it to the .dsp file. Her (admittedly
> stupid) editor either converts all the line endings, or adds the new lines with
> LF style endings. We still need a CRLF, CR, LF, etc value for the property.
Sorry, I should have said "I don't see how either of these two schemes
can prevent that". Yes, this scenario can happen, but...
If the property has a value like this, how does Subversion behave when
the given value completely disagrees with the actual line endings in
text-base?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 14:17, Kevin Pilch-Bisson wrote:
> +1 for 3a, since most decent editors won't switch all the line endings anyway,
> they will either preserve the same style, or preserve the same style except for
> added newlines.
Sadly, this is not an argument for my scheme. As long as the conversion
property is on (or "native", as I presented it), Subversion will have
already helpfully switched all the line endings, so they'll be
flip-flopped on commit even if everyone is using decent editors.
(Of course, if we get to a point where everyone has decent editors,
people won't need to set the property any more, and *then* there won't
be flip-flopping.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Dec 13, 2001 at 01:09:38PM -0600, Karl Fogel wrote:
> ...
>
> 3. This is the variation step:
>
> 3a - The exact bits of the working file are always sent to the
> repository on commit, and the repository (and text-base)
> updated accordingly. This means that alternating commits
> from different platforms would flip-flop the line-ending
> style in the HEAD; on the other hand, it guarantees that
> EOL conversion will never change the data someone thought
> they committed.
>
> +or+
>
+1 for 3a, since most decent editors won't switch all the line endings anyway,
they will either preserve the same style, or preserve the same style except for
added newlines.
> ...
>
> And of course, for files for which there is only one appropriate
> newline style, they will always have that style in the repository
> (because Subversion clients will never change their style, because the
> property won't be set), so they'll be okay whoever checks them out.
> If you retrieve them with some dav client that doesn't honor the
> property, and your platform's editor messes up the newlines, and you
> commit, well, I don't see how any scheme can prevent that.
>
Not true. A .dsp file is created on windows, checked in. A unix developer
adds a file to the build, and so adds it to the .dsp file. Her (admittedly
stupid) editor either converts all the line endings, or adds the new lines with
LF style endings. We still need a CRLF, CR, LF, etc value for the property.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 16:31, Greg Stein wrote:
> We could handle this at the "repos" layer before the FS ever sees it.
Not if we're concerned with tools which directly access the data in the
FS. We need to be able to affect reads, not just writes. (Because if
there are two tools, one a Unix tool and one a Windows tool, they each
need to get different contents from the FS or one of them will break.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > * A new scheme which handles newline translation in the FS: works great,
> > but significantly complicates the FS interface and implementation.
>
> We could handle this at the "repos" layer before the FS ever sees it.
Urk, -1. Let's please handle this stuff at the client layer and
nowhere near the filesystem, not even in repos. I don't see this as
some sort of user-visible theoretical purity, but rather a way for
developers to keep their sanity. :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 13, 2001 at 04:21:41PM -0500, Greg Hudson wrote:
> On Thu, 2001-12-13 at 15:57, Greg Stein wrote:
> > The commit email scripts are running on the server only. It would be
> > comparing two repository versions. Thus, you get huge diffs.
>
> They work against the FS? That's an issue we'd have to address, then.
Yep. They use the "svnlook" program which reaches into the FS.
> (It will be a similar issue for keywords, unless we decide to
Most likely, yes.
>...
> Here is a survey of how various schemes stumble over the multiple access
Ah. This is *very* helpful. Although the unqualified "Greg's scheme" threw
me for a bit :-) (I was all, "I don't have a scheme; I like Bruce's!")
One comment:
>...
> * A new scheme which handles newline translation in the FS: works great,
> but significantly complicates the FS interface and implementation.
We could handle this at the "repos" layer before the FS ever sees it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 15:57, Greg Stein wrote:
> The commit email scripts are running on the server only. It would be
> comparing two repository versions. Thus, you get huge diffs.
They work against the FS? That's an issue we'd have to address, then.
(It will be a similar issue for keywords, unless we decide to
de-substitute keywords on commit, which is considerably more destructive
than performing newline translation on commit.)
> Note that it isn't specifically related to DAV, but to *multiple access*
> paths. Any tool that operates against the repository is going to see large
> variances between revisions. For example: a commit email script. I envision
> a large variety of tools using scripting language bindings against the FS to
> do "interesting" things. The flip flop ripples out to them.
I'd be concerned that these same tools could have problems with files
using CRLF in the repository, if they are doing anything more
interesting than diffs between two revisions of the same file. "sed"
not finding text at the end of a line, stuff like that.
Here is a survey of how various schemes stumble over the multiple access
path problem. For the sake of argument, let's assume that all tools are
unforgiving about line endings, since the forgiving ones aren't an
issue.
* Ben's scheme: enforces LF for text files in the repository contents
(in the usual case). Tools using direct fs or DAV access work well if
they're Unix tools, but not if they are Windows tools. (We could, of
course, modify Ben's scheme to allow the repository to configure what
line ending style should be enforced for checkins, but that only works
if all the fs/DAV tools run on one platform and which platform it is
never changes.)
* Bruce's scheme: first commmit determines repository line ending style
(in the usual case). Tools using direct fs or DAV access work well if
they happen to operate on files which match their line ending style in
the first commit; they fail otherwise.
* Greg's scheme: repository line ending style varies for each commit.
Tools using direct fs or DAV access fail whenever they hit a revision
checked in with a different line ending style. Worse, tools which diff
between different revisions of the same file (using the FS contents)
produce ugly diffs.
* A new scheme which handles newline translation in the FS: works great,
but significantly complicates the FS interface and implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 13, 2001 at 03:22:05PM -0500, Greg Hudson wrote:
> On Thu, 2001-12-13 at 15:12, Justin Erenkrantz wrote:
> > FWIW, +1 3b (completely non-binding, mind you).
> >
> > "first commit wins" I shudder to think of the diffs sent to mailing
> > lists with flip-flops. It'd make it so hard to understand. -- justin
>
> Your vote seems to be based on a misunderstanding. In 3a, diffs made by
> svn would be made between newline-translated copies of the revisions, so
> they would not reflect newline flip-flops.
The commit email scripts are running on the server only. It would be
comparing two repository versions. Thus, you get huge diffs.
(unless you set some kind of diff flag, but consider a case where you want
to send the *actual* diff for some kind of synchronization via email thingy
that somebody writes)
> Flip-flops in the repository have only two negative consequences: larger
> repository size, and possible problems with non-Subversion DAV tools
> (which might have problems regardless).
Note that it isn't specifically related to DAV, but to *multiple access*
paths. Any tool that operates against the repository is going to see large
variances between revisions. For example: a commit email script. I envision
a large variety of tools using scripting language bindings against the FS to
do "interesting" things. The flip flop ripples out to them.
HTTP (DAV) is a common (primary) access mechanism, but the issue is not
inherently related to the DAV access.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 15:12, Justin Erenkrantz wrote:
> FWIW, +1 3b (completely non-binding, mind you).
>
> "first commit wins" I shudder to think of the diffs sent to mailing
> lists with flip-flops. It'd make it so hard to understand. -- justin
Your vote seems to be based on a misunderstanding. In 3a, diffs made by
svn would be made between newline-translated copies of the revisions, so
they would not reflect newline flip-flops.
Flip-flops in the repository have only two negative consequences: larger
repository size, and possible problems with non-Subversion DAV tools
(which might have problems regardless).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: line ending summary: the "Breg Hudtherton Proposal"
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Dec 13, 2001 at 01:09:38PM -0600, Karl Fogel wrote:
> Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
> more to say, feel free.
FWIW, +1 3b (completely non-binding, mind you).
"first commit wins" I shudder to think of the diffs sent to mailing
lists with flip-flops. It'd make it so hard to understand. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org