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

Re: Newlines, preserving data, and multiple access paths

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2001-12-14 23:56:35 CET

On Fri, 2001-12-14 at 17:44, Karl Fogel wrote:
> +1 on Greg Hudson's latest proposal -- and I think we're now ready to
> Actually Do It. :-)

I hope so. For a while I was afraid we had hit our first failure to
achieve livable consensus. My apologies for not realizing the
reversability thing until two days and several thousand lines of
misguided debate had already gone by.

> My assumption is that "in the working copy" means both text-base and
> working file, for the sake of an efficient is-modified-p test, and
> since the repository file is just an automatic transform off the
> text-base anyway.

Actually, I was assuming that text-base would be a verbatim copy of the
repository contents. But that's kind of an implementation detail; let's
leave that up to Ben (assuming he's doing the implementation).

> Otherwise, then the is-modified-p check has to be tweaked in a way
> that will make modifiedness checks a lot slower in some cases.

No... it just means that if the mod times force a contents check, you
have to translate the text-base contents as you compare them against the
normal contents. That's "a teeny tiny bit slower," not, "a lot slower."

> The second sentence of the above paragraph isn't about allowing
> mixed-style files. It's saying that if the entire file is native
> format, allow that (and transform when necessary), OR if the entire
> file is in the requested style, then allow that too. The latter
> situation could happen if someone used a LF-style tool under Windows,
> for example, so that when an LF-style file got saved, the whole thing
> would be LF-style now, not native style. No reason to disallow this.
>
> Right?

See my last message, as well as Colin Putney's argument. In summary,
that's not actually what I meant, but I don't really care either way.

---------------------------------------------------------------------
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.