[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] How to fix the tagline problem

From: Harald Meland
Subject: Re: [Gnu-arch-users] How to fix the tagline problem
Date: Sun, 05 Sep 2004 12:28:35 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

[Matthew Dempsky]

> (Basically, if the strings are equal then they're always the same.  If
> `strict' is 0, then we allow the length to differ by one as long as
> the rest is identical and print out a warning message.)

Personally, I *think* I'd rather have the non-strict comparison ignore
any and all CR and LF characters at the end of (at least tagline, not
sure if one ought to bother with implicit) ids.

This could then also work around the problem of various operating
systems using different sequences of characters to indicate line-end
(Developer A creates a file on a Unix box; developer B updates the
file an a windows box, converting all LF line-endings to CR+LF
line-endings, and thereby changing the file's tagline id... and so on,
and so forth).

> For the next couple of releases, we would make strict default to 0 and
> provide a --strict-id-matching option to all appropriate tla commands
> to override this.  After that, deprecate the old file ids and change
> the default to 1 and instead provide --loose-id-matching.  Finally
> after that, we can prune the code and change it back to str_cmp.

Why is it a good idea to consider CR and LF characters at the end of a
tagline line as part of the id?  Is it really plausible that changing
the code now will cause any conflicts to occur?  If yes, wouldn't
adding a "--strict-id-matching" option as you propose be a better
workaround (i.e. allow people with such conflicts to do their work)
rather than "decaying" back to the previous
"line-ending-characters-are-significant" behaviour?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]