At 11:46 AM 12/12/2001 -0600, Ben Collins-Sussman wrote:
>This has nothing to do with any EOL translation scheme. The user has
>the responsiblity to make sure that svn thinks a file is binary. svn
Exactly. I was addressing Greg's argument that his method kept files from
being altered if the property is set incorrectly, whereas on multiple
platforms it does not. I understand what he was meaning now, though, since
it turns out there is alteration of the file in your old system even if you
don't change platforms.
>That is what was meant; see my latest mail supporting greg's
>proposal. I think it makes things much clearer.
In that case, I guess I should submit a proposal of what I understood your
proposal to be, since I think it has the benefits of Greg's system without
requiring the flip-flopping of line endings in the repository.
1. To the repository, all it is storing is data in files. Therefore it
makes no alterations to the data in any file. If the file requires line
separators, they may be of any type, and different files can have different
types in the same repository.
2. The client, when it is retrieving files for a particular platform, is
concerned with making sure that files that use line separators contain the
right kind of line separator for the platform. Therefore, when checking out
or updating files, it may choose to alter the file so that the line
separators match local usage in the working copy. The text-base is always
identical to the repository.
3. When committing files, the client is responsible for storing them in the
repository exactly as they appear in the working copy, _unless_ the client
altered them on checkout. If they were altered, the client is responsible
for performing a reverse alteration on them first before checking back in.
This means that line endings are converted back to whatever format the
repository expects them in before a commit.
4. When you first add and commit a file, Rule 3 still applies. It was never
checked out so it is sent to the repository with no changes.
I've talked about line endings here, but the transformations could
potentially be keywords, ASCII to EBCDIC, language translations, whatever.
It is just the client's responsibility to undo whatever categories of
changes that it makes when retrieving files.
When you stick to a single platform, your files in the repository will
always exactly reflect what you created, just as Greg's solution does. When
you go to multiple platforms you will get corruption if you have not set
your properties correctly, but that is true of Greg's solution as well.
Really, they have very similar behaviour except that the line endings in
the repository remain constant.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:52 2006