attached mail follows:
From: Ben Collins-Sussman [mailto:sussman@collab.net]
>Billy Tanksley <btanksley@hifn.com> writes:
>> This would result in svn acting like CVS -- it'd appear to
>> corrupt binary
>> files. (Of course, the binary file can simply be changed to
>> actually be binary, in which case everything's fine.)
>Well, again, this is user error. If a file is binary, make sure svn
>thinks so. It already has a heuristic for guessing... and you can
>always directly tell it so.
>And most importantly, the corruption never *really* happens, at least
>not in Greg's system. The original version in the repository is
>always uncorrupted, as is any text-base copy that somebody gets. Any
>'corruption' is purely a superficial thing that only happens in the
>working area. A user can easily revert the working file and make sure
>no translation happens (though any number of methods.)
I do like this property. It may be that this is the only possible
compromise between the two camps.
It's just odd that this transform should be built into the software, while
other equally valid ones are bolt-ons. For example, people were talking
about C++ code being automatically deformatted (perhaps one word on each
line) on checkin and then reformatted on checkout. Not everyone will want
this -- but for the ones who DO want it, the argument is almost exactly the
same as the argument for line ending conversion.
Perhaps that's the answer -- make line ending handling into an 'external'
feature (i.e. one which uses the extension API), which just happens to be
shipped with Subversion. It can be an example of how to use that API, so if
someone wants to build that C++ reformatter, they can use the line ending
formatter as a starting point.
Best of all worlds -- and if someone really gets irritated with it, or
doesn't need it at all, they can just unplug it, because it's nothing but a
pre and post-processor.
-Billy
---------------------------------------------------------------------
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