Hi,
I know, another proposal. This probably overlaps
with the other proposals in a major way, but I
just want to get this off of my chest.
In this proposal I will only speak of files that
have a property set which shows they are text files.
General
=======
- The repos stores the data the way the client
sends it. IOW, the server doesn't do any
conversion, the client does.
- Files will have an eol property. This property
can have the following values:
- <non-existent>
If the property doesn't exist, check the parent
directory for this property. If that isn't set,
bubble up further. If the property is non existent
the entire path up to the root in the repos, default
to "none".
- "none"
No conversion ever happens.
- "cr", "lf" or "crlf"
The EOL style of the file in the repos.
Checkouts and updates
=====================
- On checkouts (and updates) the client checks to see
if the eol property on a file differs from its native
eol style. If so (and the style is not "none"), it
converts the file in the working copy (not in the
textbase) to native style.
Commits
=======
- When committing a new text file, set the eol property to
the native style of the client (ie. on windows this would
be "crlf"). This behaviour could be overriden in the
svn configuration file. In the config(!) eol could have the
following values: "none", "cr", "lf", "crlf" and "native".
The last value reflects the default behaviour.
- When committing an existent file the client _always_
converts the file to match the eol property (unless it
is "none" ofcourse). After the conversion it is diffed with
the text base and sent off as usual. This convert and
diff step could be done using an intermediate file, if people
worry about it.
Exports
=======
- When exporting you should be able to specify the style you
want through a command line option. If you don't give
the option it will default to native. So:
$ svn export --eol=crlf http://server/repos/project
will give you the project with all text files (with a eol
property other than "none") having CRLF line endings.
That's all. And again: Sorry to post again on this issue,
Sander
---------------------------------------------------------------------
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