use external diff tool in the ignore line-endings mode for merge

[Frits Jalvingh]

No, I had only about 15 branches to take care of, and that took only a few
hours of work and testing. During that time no one could work on the
branches. In addition, we converted all branches that really needed to
merge at some later time; all branches that were still present from before
the "conversion" could not be merged anymore - they will indeed cause
conflicts.

So it really depends on whether you have some form of control over the
branches - we had, and we just merged all work that was finished first, and
then converted all branches that were left so that they would cleanly merge
after the conversion.

Old checkouts, as long as they are just representing the base state of a
branch and not have "old changes" anymore will just be usable as long as
you update them to the latest version of the converted branches they are
based on. And that should be done before work on them is continued.

There is one special thing to really not forget: there is an extra thing
you really need to do if you also decide to start bazaar line endings
support (using a rules file). In that case it is pretty much mandatory that
all of the branches that have working trees (so basically everything on a
workstation) are destroyed and checked out again, because bazaar's line
ending support is not properly integrated with the branch, and it creates
really horrible problems when you enable a rules file on an existing tree:
it will suddenly decide lots of files are changed, or mark files as changed
regardless of how much you commit).

The spurious commits due to line ending differences are of course very bad,
especially if you have, like us, a lot of related versions of a product to
maintain. But if you do the conversion and handle that rules file thing
then they are really gone. It however is very error-prone because of the
need to have the exact proper configuration on each and every workstation,
so anyone that forgets it will mess up the repository badly.

About the Git thing: we did quite some research and moved to bzr a few
years ago. We are a Java shop, and solid rename support is a complete must
for us. Neither Git nor mercurial has anything workable there. In addition
bzr has by far the best user interface (command line), which is really
important since we want to focus on learning how to code well, not on how
to do version management ;-) The worst thing about Bazaar for us is the
trivial way in which you can more or less destroy your repository - but we
learned to live with that.

Mercurial's user interface is just not very good (look at how to resolve
conflicts for instance, and how easy it is to lose all your conflict
resolutions), but git is really, really making you want to gauge your eyes
out. It is immensely capable and actually solves a lot of problems in
mostly the right way (line endings for instance, sigh) but it's learning
curve is abysmal and it's complexity staggering. I would really like to not
have to explain it to my co-workers..

We also have a big investment into a toolset surrounding Bazaar: a tool
(the Puzzler) which completely handles our fixing and release process,
which uses bazaar to maintain several versions of a product at the same
time, making it possible for a developer to create one fix (a bazaar
branch) which is then just sent to that Puzzler which will merge it to all
required versions, do technical validation, allows for code review of the
change on all versions before merging, and finally after acceptance create
the binary fix packages ready for install for each version.
Since Bazaar development has effectively stopped I am starting to look to
something else (no hurry though) but at this point I think Mercurial is the
better choice for us...



On Tue, Dec 11, 2012 at 5:47 PM, Fredrik Stax{ng <fstx at update.uu.se> wrote:

> Thank you for your reply.
>
> I might have to do something like this. Did
> you make everybody check in their code during this procedure? What
> happened to the old checkouts after you enable eol?
>
> In my experience, using eol on a non-eol checkout, or vice versa
> generates a lot of spurious modifieds. Also, if somebody checks in
> without eol, eol users will get CR-CR-LF. That actually breaks a lot of
> things.
>
> Also, I have to wonder why you did not switch to git.
>
> Frits Jalvingh <jal at etc.to> writes:
>
> >Hi,
> >
> >We had this same problem: a repository consisting of multiple branches
> >representing different versions of the same product. All kind of files had
> >bad line endings.
> >
> >We actually fixed it in the repository and it is not that hard at all
> >provided that the branches you do have now can merge properly.
> >
> >What you do is more or less this:
> >
> >1. You make sure you have crlf support in bzr disabled for the change (no
> >"rules" file)
> >2. Check out all branches in some work area
> >3. Define the proper merge order of those branches
> >3. Starting at the "lowest" branch (the branch that merges into the next
> >one(s)):
> >4. convert all of the files to the proper line endings (we chose LF,
> >because we enabled Bazaar's line ending support after the change. It is
> >quite badly implemented but it is better than the anarchy that resulted
> >without it).
> >5. Commit that change on that branch - this one is now clean, and the repo
> >representation for it has only lf.
> >6. Move to the next branch, and merge the cleaned one in there. This can
> >generate a /lot/ of conflicts. Just ignore them and do "bzr revert ." Take
> >care: the dot after the revert, indicating the current directory, is
> >actually important: it tells bazaar to undo all changes to all files /but
> >it keeps the merge recorded/ - which is the important part!!! Do not
> commit
> >yet.
> >7. In the same branch again convert all line endings to lf, and commit.
> >This commit now has done 2 things:
> >-- it recorded that the merge with the earlier branch was done, so it will
> >not be retried
> >-- it has changed all files to lf ;-)
> >
> >You basically repeat this process over all possible branches. It is
> >important to hit 'm all and merge the changes through upwards in one go,
> >because merges that pass "over" this change point will be problematic.
> >
> >After this you can try to enable bazaar line endings support by adding a
> >rules file to every workstation and hoping your developers will not forget
> >to reinstall it when they reinstall their OS....
> >
> >Greetings,
> >
> >Frits
> >
> >
> >On Tue, Dec 11, 2012 at 7:25 AM, Fredrik Staxeng <fstx+u at update.uu.se
> >wrote:
> >
> >> Aaron Bentley <aaron at aaronbentley.com> writes:
> >>
> >> >On 12-12-09 03:14 AM, Fredrik Staxeng wrote:
> >> >> If anybody has done this, I would be very grateful for any details
> >> >> that you can tell me. Which version of diff3, perhaps where to get
> >> >> it, and how get bazaar to use it.
> >> >
> >> >As far as I know, all versions of diff3 work.  You tell merge to use
> >> >it by specifying --diff3 to "bzr merge".  If you want to standardize
> >> >on diff3, I recommend aliasing "merge" to "merge --diff3", e.g. "bzr
> >> >alias merge=merge\ --diff3"
> >> >
> >> >Aaron
> >> >
> >>
> >> Well then, please name one.
> >>
> >> Just to make sure you understand the problem.
> >>
> >> If you do bzr update on a bound branch, and the line endings has changed
> >> in a file, the result is a "merged" file that consists of the whole of
> >> f.THIS, followed by the whole of f.OTHER.
> >>
> >>
> >>
> >> --
> >> Fredrik Stax\"ang | rot13: sfgk at hcqngr.hh.fr
> >> This is all you need to know about vi: ESC : q ! RET
> >>
> >>
> >>
>
> --
> Fredrik Stax\"ang | rot13: sfgk at hcqngr.hh.fr
> This is all you need to know about vi: ESC : q ! RET
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20121211/6a7f23d3/attachment.html>