On Tue, 2001-12-11 at 14:43, Karl Fogel wrote:
> I reread Ben's document, and your paragraph, and I'm still not
> understanding the problem. Sorry, could you be more verbose?
During a commit operation for a file, there are three potentially
different states of the file contents to consider:
1. The bits of the file on disk, before the commit command is run
2. The bits which are committed to the repository
3. The bits of the file on disk, after the commit command is run
I assert that (1) and (2) should always be the same, to avoid
irrevocably destroying data, even though that means the repository has
to store some gratuitous diffs a lot of the time. However, (3) should
be different; we should do a keyword substitution on the file after we
commit it, since certain keyword tags will become different as a result
of the commit. (No compelling reason to do a newline substitution,
though.)
> Greg, it might actually be most helpful if you'd describe your ideal
> newline conversion system, in detail and without reference to any of
> the other proposals. (Or have done this before, and I'm just not
> finding the post?)
Well, there are a lot of details I don't care about, so I haven't
created a complete proposal. But I can try:
* Each file has a property, let's call it "svn:newline-style", which
can have values "native" and "none" as well as "CRLF", "LF", or "CR".
(Or maybe "DOS", "Unix", and "Mac" for those last three; doesn't
matter.) Let's say the default is "none", based on the recent traffic
on this list. Let's also say that the property is inherited from the
directory when a file is created, when we get around to worrying about
inherited properties.
* The text-base file is always a pristine copy of the contents from
the repository.
* The operation of "newline transformation" on a file is to transform
anything which looks like a newline (CR, LF, CRLF) into the style
dictated by svn:newline-style. No newline transformation is performed
if the svn:newline-style is "none", or if the file is binary according
to its MIME type. (This means there is no way to force newline
transformation on a binary file, but means you can safely let
svn:newline-style be inherited by binary files without fear of damage.
If we really really want to allow people to force newline transformation
on binary files, we'd have to tweak things a bit.)
* When a file is checked out, we do newline translation when we copy
text-base to the working dir. Same for an update (I'm not precisely
sure how to handle the merge case since I don't know which direction we
do merges. We probably have to do newline translation on both the old
and new text-base before doing any comparisons.)
* When we do an "svn diff", whenever we use a text-base or retrieve a
revision from the repository, we do a newline conversion before running
the diff--even if we're comparing two versions from the repository, they
might have been checked in with different newline styles.
---------------------------------------------------------------------
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:52 2006