[MERGE REVIEW] Tweaks to bundle merging

[John Arbash Meinel]

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

John Whitley wrote:
> Martin Pool wrote:
>> Therefore I suggest we add a field to the diff header saying what kind
>> of newline is used in lines added by that diff.  This should be
>> reasonably straightforward to add as an option to the method that
>> produces this from a SequenceMatcher.
>>
>> --- a   2006-06-15 06:36:02.000000000 +1000
>> +++ b   2006-06-15 06:36:03.000000000 +1000
>> ~~~ line-endings: CRLF
> [deletia]
> 
> I'll observe that this can/will dovetail with versioned property based
> line-endings support ala http://bazaar-vcs.org/LineEndings.  Once bzr
> supports line-endings, then that information (and the actual filters)
> can be used to assist in just this situation.
> 
> As for mixed line endings, the only real case that I've been able to
> come up with is that of a test case file that deliberately includes
> mixed endings to test the behavior of the associated app.  In this case
> the mixed-ending file should just be treated as a binary[1].  Otherwise,
> I'd suggest holding the line that "text file" means "text file with
> consistent line endings", and let someone who disagrees write a plugin
> to extend the line-endings property support for their real-world
> mixed-ending use case.
> 
> -- John
> 
> [1] On which I note that there's no option to "bzr add" to force a file
> to be treated as a
>     binary.

Well, at present all files are considered 'binary', as in bzr doesn't
change anything about the bytes. (The are always perfectly preserved).
The only thing we do with the binary check right now is not display the
diff by default.
It is hard to get it right. CVS is a pretty huge mess (especially if you
have people committing on multiple platforms). And SVN tried harder, and
maybe gets it better, but also has a very complex system that takes a
lot of tweaking of the properties to get it right.

Right now, it still seems that staying with binary is the safest.(use
line endings for merge, but generally just preserve the bytes as they
were created). We can add a lot of work to try and handle the different
cases, but you end up getting almost as many wrong when you try and fix
the other ones. And getting it wrong means you may have corrupted your
commit, (as in an unusable revision), rather than a big diff.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkNAQJdeBCYSNAAMRAmsRAKCo9gOQXCJsfk8cFqiXjYpDkAP7TwCfUNRo
TFc3uBvx4jjB0oVmhDcJXqg=
=9/Dd
-----END PGP SIGNATURE-----