On Sun, 2009-09-27 at 18:37 -0700, Charlie Poole wrote: > Hi All, > > Several of my projects (e.g.: nunitv2, nunit-3.0, nunit-summary) > started out on windows and have crlf line endings. Now that > I've got a few people working in linux, we are starting to > see issues with our diffs, with the real changes buried in > the midst of a bunch of line ending changes. > > I've looked at using the eol setting in the rules file, but > I have a 'few' questions... > The best documentation I have seen on the subject of bzr rules for eol handling appear in the bzr user reference[1]. > 1) Will using this filter require updating each dev's repo > format? What about the format on Launchpad? > Only if the repo format version is less than "1.14", bzr info -v will show the format even for remote repositories as long as the access method is sftp or http, not bzr+ssh! To enable this you'll need bzr version >= 1.14 on everyone's machine who'll be contributing (this will be a natural outgrowth of upgrading the repository format at least to "1.14"). > 2) How can I ensure that everybody uses the proper eol value? > Set the rule for everything that isn't platform-specific to "native" or "native-with-crlf-in-repo". DOS- or Win-specific files like batch files (*.bat) can have a rule "crlf" while *nix-specific files like shell scripts (*.sh) can have a rule "lf". > 3) How can I initially force all the stored line endings to > the selected value? Or do I have to do that? > No need to initially force all stored line endings to a particular value because after you upgrade the repository and set up the rules the next commit of each file will change the line-endings of that file to conform to the rules you have set up. > 4) If I do make such a change, will it mess up the history? > The automatic change at the next commit should not mess up the history. The diff will merely show unannounced line ending changes if the rules specify a change. > 5) Am I better off using native or native-with-crlf-in-repo > in this situation? > I would suggest native for a new project but native-with-crlf-in-repo for this situation as this will not introduce any superfluous line-ending changes in the history. > 6) Is this likely to get easier in the future and - if so - > am I better off doing something temporary for now and > planning on a major change later? > I doubt the situation is going to become simpler. I suspect this is a case of irreducible complexity. On the other hand, a reasonably simple set of rules will allow you to avoid a lot of grief as bzr will just make sure your file abides by the line-endings you specified in the rules configuration when it commits changes to a file! Recommended rules file: $BZR_HOME/.bazaar/rules ------------------------------------------------------- [name *.png] eol = exact [name *.bat] eol = crlf [name *.sh] eol = lf-with-crlf-in-repo [name *] eol = native-with-crlf-in-repo ------------------------------------------------------- Commentary: The first rule is for binary files that may not have a null byte--bzr won't even try to change their line endings. Next is for a file that is native to CRLF environment (MS-DOS, Windows). Then we have a rule to avoid unnecessary line-ending changes in an already CRLF repository for a file whose native environment uses LF line-endings (Linux, *nix). Finally, for everything else, leave the repository in CRLF but use the native format for working trees. This avoids further unnecessary line-ending changes. Let me know if you have more questions about bzr or if any of these answers miss the mark or bring up other questions. Richard References: [1] http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion -- PGP public key at http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xA7CEB3C711AFF0B0
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)