Rob Hubbard wrote:
> Thanks for the reply Nico.
>> 1: Work out a way to force svn:eol-style going forward. You don't
>> want this
> happening again.
> Well, I suppose that pre-commit could check all added files for
> either the presence of a valid svn:eol-style property or explicit
> membership of a list of permitted exclusions (such as *.gif files).
>> 2: Convert every appropriate file as determined by those new
>> policies that
> should have an svn:eol-style set.
>> 3: Use dos2unix or unix2dos or a tool like that to convert every
>> file. 4: Commit them as changed.
>> 5: Set every darned file to the new style.
>> 6: Commit that.
> What's reason for using this many separate steps please?
To make sure they all happen, in order. I'm a big believer of giving
checklists to people doing something the first time.
> I'd assumed I could simply set the svn:eol-style on all appropriate
> files and commit; I think SVN itself modifies the files (in the
> repository, at least) on the commit. Or am I mistaken? (My working
> copy might need a "downdate"/update-cycle to deal with the working
> copies of files, perhaps.)
Nope. You've already got the files in place, and will wind up with looniness
such as excess EOL characters of the wrong type in the most unexpected
places. It's much cleaner to reset the currently-binary-stored files first,
then inflict the EOL on them. The other way around doesn't work well.
>> dos2unix and unix2dos are built into most UNIX-like systems and
>> CygWin these days.
> Yes; for badly conflicting files, dos2unix could be applied to the
> triple of input files SVN produces (*.mine etc.) and then diff3 or
> diff/patch could be applied again manually. Hopefully that would
> result in smaller, more localised conflicts, rather than
> whole-left-file/whole-right-file conflicts.
> Is there any way to get SVN to use programs like diff and patch with
> end-of-line-insensitive processing in the first place, rather than
> dealing with poor merge results afterwards?
I've not tried it:
>> You really, really, really want that pre-commit going forward.
> Okay. Yes, that would protect against users not having their
> autoprops set correctly.
Yeah, that's why I have pre-commits that say "you must have comments! Not
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Aug 15 17:41:06 2006