line-ending conversion (was Re: Bazaar as Subversion replacement)

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool пишет:
> On 16 Jan 2007, Alexander Belchenko <bialix at ukr.net> wrote:
>> Marius Gedminas пишет:
>>> On Tue, Jan 16, 2007 at 10:09:04PM +0200, Alexander Belchenko wrote:
>>>> Don't understand me wrong.
>>>> I know that reading files from disk and writing them back is the simplest
>>>> part of line-endings support. I realize that proper support requires also
>>>> new inventory format to store file type and all other stuff, that Aaron
>>>> already mention in this thread.
>>>> So it's looks very simple from user point of view, but I'm aware about
>>>> underwater body of iceberg.
>>> If .bzrignore at the root of the branch is enough to support ignored
>>> files, wouldn't .bzrlineendings suffice for specifying which files need
>>> what sort of line endings?
>>>
>>>   *.py = native
>>>   *.bat = CRLF
>>>   *.sh = LF
>>>   subdir/somesortofexception.sh = binary
> 
> That kind of approach seems to me to make more sense than per-file
> properties.  In svn, it is easy for people to forget to set the right
> property on a file, and then that revision will always be wrong.
> And this is precisely the sort of feature which we want to have work
> correctly even when most of the users don't understand it or know it
> exists, and in most trees a small number of globs will do.

This file (I prefer to name it .bzreol because .bzrlineendings too long
to type) is not enough. If someone write the specification before code
it easy to see that using only this file has following weakness:

1. During checkout of some revision or initial checkout of branch
the file .bzreol should be extracted first and then used to
handle all other files
2. During commit bzr should use settings in .bzreol before read
files from disk and store in repository. That in turn lead us
to next problem.
3. During partial commit it's easy to exclude .bzreol from commit
and potentially have wrong line-endings settings that come into
repository and easy to broke some file accidentally (as John points).
And user don't notice about this until actually to checkout this
revision.
4. How to handle situation when user change settings in .bzreol
for some files?

Storing eol property in inventory effectively solve this problems.
But the file .bzreol anyway useful: it will be used as rule
for adding new files to tree.

> 
> John alluded to the danger of
> 
>  * = native
> 
> and then checking in a binary file such as an image.  As a safety
> feature we could noisily refuse to do conversion on files that look like
> binaries (contain \0 etc).

It's not enough. Binary files sometimes may not contains any \0
but anyway it's binary file.

>>> If the number of per-branch configurable options is going to be larger,
>>> maybe it is time to consider a .bzrbranch.cfg with sections, e.g.
>>> something like
>>>
>>>   [ignore]
>>>   *.py
>>>   *.svn
>>>
>>>   [eol-style]
>>>   *.py = native
> 
> I think for now I would keep them separate.
> 
> Some people would prefer no (or at least minimal) vcs cruft in the tree,
> with these files inside .bzr or as special hidden properties.  But I
> think we can go ahead with regular files for now.

Having the file .bzreol inside .bzr is more robust about point 3 above
(partial commit). But in this case user somehow should to know where to find
this file.

Alexander

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFrf+wzYr338mxwCURArLjAJ4kxN5zCxjqgTDGQDCUI/G/5fqkfACfUJ3v
ZQpyMjFbJjUV51ELoMqpR8c=
=2Ox1
-----END PGP SIGNATURE-----