Change from tla to bzr

[John Arbash Meinel]

Szalay Attila wrote:
> Hi All,
> 
> We use tla as the main vcs in our development. But we have reached some
> bottleneck and because of it we have decided to switch (partially) to
> other vcs.
> 
> I am trying bazaar-ng as an alternative and I have realised that there
> are some features that I not found in bzr.
> 
> But before I could ask the questions, I have to describe our branching
> (and merging) policy. (When I try to convert our tla archive to bzr
> archive there were 960 branches)
> 
> We have a branch called mainline and every  developer has his/her own.
> When a developer fix a bug or implement a new feature in his own branch
> a tester try it and accept it or not. If accept it the patch (or
> patches) will be cherrypicked to mainline. After some time every other
> developer synchronise his/her own branch to mainline to pick up other
> developers patches.

Does it have to be 'cherrypicked'? It seems like you could just merge
the changes.

> 
> But in this synchronisation  process there were a trick. First we tried
> star-merge but this allways failed because of the cherrypicking. So we
> chose using apply-delta. But because of this a lot of patch (every patch
> that was not merged to mainline) fall out from the working tree (because
> it's pachlog were deleted) and we have to "merge" it (with replay)
> again. But that was good, because in this situation, the conflict (if
> there were any) was in the little patches what the developer do and
> he/she knows better than any other developer.
> This method give us an another good thing. The possibility to fix
> something in a previous patch. I try to explain this:
> 
> The developer have done 3 patches to a.c This patches do orthogonal
> things (for example add 3 new function to it). After a while I try the
> first patch, but there are problems with it. The developer easily fix it
> in his/her 4. patch but I cannot pick his/her 1. and 4. patches because
> the 4. patch depends (for example) the second. So I try the second but
> that fail too. In the end there maybe 10 or more patches to fix 4 (or
> more) bug, and I can only merge it together and this is raises problems.
> 

So you have 3 orthogonal patches, and then you want to cherry pick a new
4th patch. Is that correct?

> 
> So the question is:
> 
> How can I synchronise my developer branch to mainline when in mainline
> there is patches from other branches and cherrypicked patches from my
> branch with as small conflicts as possible? And it's maybe an extra if I
> can "upgrade" my patches somehow in this process.
> 

Right now, bzr doesn't record cherrypicks. So while you can do:
	bzr merge -r 10..11 http://other/branch
Which will merge just the change between revno 10 and 11 (effectively
the patch for 11), it won't record that the change was taken from
other/branch.

However, because of how bzr does merging, it can be a little bit better
about it than tla was. 'bzr merge' and 'bzr merge --merge-type=weave'
have the ability to do some pretty advanced merge logic.

Also, there is the possibility of merging another branch, and then
rejecting some of their changes. So if you did:

	bzr merge http://other/branch
	bzr commit -m "committed the merge"
	bzr merge -r 11..10 http://other/branch
	bzr commit -m "rejecting patch 11 from other/branch"

At this point, bzr would say that you have fully merged 'other/branch',
and undid some of the changes. A future merge will most likely ignore
the changes introduced in 11.

Now, with tla if you did 'tla missing', it would probably show you that
you didn't merge patch-11 (unless you go through the sync-tree song and
dance), and bzr won't tell you that. It really depends on what you need
with cherrypicking.

One thing that could definitely change for you is that bzr doesn't
require a star formation. You can use mesh merge (where any developer
can merge from any other developer, they don't have to go through mainline).

We probably could come up with a workflow that will work for you. But it
may need to be different from what you have been doing with tla.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060525/221e95c5/attachment.pgp