Re: [Monotone-devel] line endings

[Yury Polyanskiy]

Well I think per-file certificate is something that doesn't fit in
monotone's model (certificates are attached to revisions not files).

In fact I think current implementation with get_linesep_conv() includes
every other model IF only I could check for "merge_manual" attribute
from inside the hook. As nobody answers I assume monotone doesn't have
internal mapping filename->attributes which can be checked from hook.

BTW, I don't understand all the buzz about bad binary files handling.
Maybe monotone COULD improve heuristics about detecting binary files but
in any case user has complete control over the process by setting
manual_merge attribute.

Overall I see two problems with line endings by now:
(a) conversion should not touch CR's if I want to convert LF's only.
(b) it should be possible to check for manual_merge attribute from hook
(c) default get_linesep_conv() should return {"LF", SYSTEM_SEP } for all
files which are not marked by manual_merge attr.

That I think would satisfy everyone and does not (except for b) imply a
great change in current code. 

BTW can anyone knowing rosters stuff say if "better attributes handling"
may now help with (b) in the above?

Yury.



On Wed, 2006-02-01 at 18:59 -0800, Howard Spindel wrote:
> It seems to me that to be completely general monotone needs a 
> per-file certificate specifying the permissible 
> transformations.  Examples of the settings available in that certificate:
> 
> 1.  Never transform anything
> 2.  Database file is LF line terminated, transform LFs to platform 
> specific in/out
> 3.  Database file is CR/LF line terminated, transform CR/LFs to 
> platform specific in/out
> 4.  Whatever additional combinations are possible (does monotone have 
> to worry about big-endian vs little-endian ever?)
> 
> "Platform specific" could be determined by system call, overrideable by hook.
> 
> Monotone would request the correct setting on initial file 
> check-in.  For backwards compatibility, if the certificate does not 
> exist monotone does whatever it does now but requests the correct 
> setting on next file check-in.
> 
> The problem I see in the discussions so far is not in knowing what to 
> do on the platform you're on, but in knowing what's stored in the 
> database.  Monotone could use heuristics to determine that, but if 
> the heuristics fail the user gets a big, maybe nasty surprise.
> 
> In a project development environment where everyone uses the same OS, 
> "never transform anything" should work well for all files and perhaps 
> there should be a way to tell monotone that this case exists.
> 
> Since I know nothing of monotone internals, I acknowledge that I 
> could be way off-base on something here.
> 
> Howard
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel