On Sun, Oct 16, 2011 at 12:36 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
>> On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>>>
>>> Perhaps a better approach, especially if you know people will be using
>>> git-svn, is to review the repository for any files that use svn:eol,
>>> and *turn that off*, with a check that the binary EOL is the format
>>> you want. Then put in a pre-commit hook to prevent anyone using it.
>>
>> But a binary EOL is almost never works for cross platfom text. Which
>> is why systems designed for cross platform work do the conversions.
>> How do git users deal with it?
>
> [ Allow me to put on my lecture hat. ]
>
> You've made me think about this, thank you. I can't speak for all git
> users: I use what tools work, and that's sometimes Subversion and
> sometimes git (for reasons I won't go into here).
>
> This is one of the things I prefer about git. Cross-platform source
> control systems which try to do this EOL handling for you *break*,
> predictably. It used to drive me bugfutz with CVS. By git standards,
> the file being checked out on one machine should match the code being
> checked out on the other machine in every byte. If you need to
> transform it to use it locally, that's a build environment issue,
> *not* a source control one. Treating it as a source control issue
> breaks things and, in my opinion, shoudl be deprecated, the same way
> that the ftp "text" format is also deprecated.
>
> The git model for EOL is safer, to my mind, because it is
> *predictable*. You know what you're going to get when you do a
> checkout. If you need to, you can have a local transformation utility
> for yet another "clone" that does not ever have to be transmitted
> back and corrupt the central repository. It can push to a staging git
> repository where these discrepancies can be resolved, and never
> corrupt the "mastter" repository.
>
> The Subversion model "you have to set svn:eol" is workable for a few
> isolated cases, but should be used only with caution. It should
> *never* be applied to a source tree: the risk of precisely this kind
> of mismatched working environment is too frequent. I've loathed
> having to enforce it for default checkins, which I've enountered,
> because it contributes to just the kind of sourcecode madness we just
> saw.
I don't really understand (the need for this lecture). If you don't
want to use the svn:eol-style feature, just disallow it with a
pre-commit hook (and all files will be committed 'as is'). I happen to
use this feature, and I'm quite happy with it.
In my mind it's quite simple:
- There exists a feature called "svn:eol-style=native".
- It's useful for some people (other people may wish to not use it).
- This feature is quite well defined.
- It has limitations (f.i. it's not a good idea to share working
copies accross multiple platforms). These are known.
- The deal is: svn clients must follow the specification, which means
they must transform EOL's to LF when eol-style=native.
- I don't care how a client does this, or what philosophical /
religious arguments there are about this. If a client does not play by
the rules, it violates the spec. That should be blocked by the server
(or we should at least have the ability to block this faulty client
behavior).
--
Johan
Received on 2011-10-16 01:16:26 CEST