Bazaar

Bazaar with central repo : how to solve "merging hell"?

Asked by jean-michel

Hi guys,
in my previous job we used to use svn extensively and I am taking advantage of a "professional break" to try to famliarise myself with DCVS tools and contonuous integration environments.

I decided to give a try to Bazaar as it seems prety nice and hype, but after smooth first steps, it is all going pershape, so there must be something I am doing wrong.

I did set up an Ubuntu (10.10) server with Bazaar and CruiseControl.
Having a central repo felt natural to me (cause of my history) and it is necessary anyway for CruiseControl or any CI tool, as tehy need to be able to pull the last sources from somewhere.

I the workflow I had in mind (and tried to simulate), the 3 developpers (Liz, Bob and Paul) work with a local repository on their desktop and therefore local branch, commit locally till they are happy with their code, then push to the central repo, as it is all XP and CI, they need to push their at least at the end of each day.

So it is 5:45pm, the developers have to push their code.
THEY ALL WORK ON DIFFERENT PARTS OF THE PROJECT WITH NO "REAL" CONFLICT.
Liz shoots first, and everything is fine, she is off to the pub!
A few second later, Bob pushes his changes, but he is told that his local copy has diverged, and the same happens to Paul.
Both Paul & Bob merge their own local branch with the central branch (when they'd really want to shoot out to the pub).
Paul commits locally and pushes his changes and they go through.
Bob (fair to say that he is a bit slower) does the same, but when Bob commits and pushes his changes, his local branch still diverges (because of Paul's commit). Bob has to merge again.

So not only Paul and Bob will be late for the beer, but the revision tree will appear all clutered with uncessary merges and paralle branches.

It appears as well that this will be slightly confusing for the continuous integration tool as Paul weill appear to have modified his own source files, but as well Liz's modified files and it will be even worse for Bob who is likley to appear as a cullprit for Liz's, Paul's and his own changes.

So this is just for 3 developpers, but I cannot even imagine the headache in a bigger team (some will not have a beer at all and will even miss diner!).
There must be something I got wrong in my workflow or set up.

Maybe there is way to do a "loose push" ala svn commit where conflist are only checked for modified files (though it is not documented and does not seem to be in the philosophy of Bazaar)?

I liked some of the features of Bazaar (local commit, ability to do a local branch) and the merge (UI tool) is much better than SVN's, but if this "merge hell" cannot be overcome, the price seems to high to pay as soon as you are a ream of more than... one(?).

Anyway, I am fairly confident there is something flawed in my workflow or something I missed.

Thanks in advance for your help.

--
Jean-Michel

Question information

Language:
English Edit question
Status:
Answered
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Jelmer Vernooij (jelmer) said : 		#1

On Sat, 2011-04-23 at 12:05 +0000, jean-michel wrote:
> New question #153952 on Bazaar:
> https://answers.launchpad.net/bzr/+question/153952
>
> Hi guys,
> in my previous job we used to use svn extensively and I am taking advantage of a "professional break" to try to famliarise myself with other CVS/DCVS tools.
>
> I decided to give a
 This question seems to be incomplete.

Cheers,

Jelmer

Revision history for this message
jean-michel (jeanmichel-cazaux) said : 		#2

Hit send too soon and inadvertently, sorry, now completed.

Revision history for this message
John A Meinel (jameinel) said : 		#3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...

> I the workflow I had in mind (and tried to simulate), the 3 developpers
> (Liz, Bob and Paul) work with a local repository on their desktop and
> therefore local branch, commit locally till they are happy with their
> code, then push to the central repo, as it is all XP and CI, they need
> to push their at least at the end of each day.
>
> So it is 5:45pm, the developers have to push their code.
> THEY ALL WORK ON DIFFERENT PARTS OF THE PROJECT WITH NO "REAL" CONFLICT.
> Liz shoots first, and everything is fine, she is off to the pub!
> A few second later, Bob pushes his changes, but he is told that his local copy has diverged, and the same happens to Paul.
> Both Paul & Bob merge their own local branch with the central branch (when they'd really want to shoot out to the pub).
> Paul commits locally and pushes his changes and they go through.
> Bob (fair to say that he is a bit slower) does the same, but when Bob commits and pushes his changes, his local branch still diverges (because of Paul's commit). Bob has to merge again.
>
> So not only Paul and Bob will be late for the beer, but the revision
> tree will appear all clutered with uncessary merges and paralle
> branches.
>

So, the biggest thing here is to separate out the concept of
"repository" with the concept of a group of files that are conceptually
together.

You mention that there is no "REAL" conflict. That likely means that
those parts of the codebase should be logically separate.

SVN always versioned everything in one big filesystem. Generally all
DVCS treat a "tree" as atomic. (in SVN one commit is atomic, but it
allows people to race at committing separate files, leaving the tree in
a potentially inconsistent state.)

So generally, if Liz, Bob and Paul are all working on something that is
logically distinct, you would have it in a separate branch.

For example, in SVN you might do:

/trunk
 /app1
 /app2
 /libfoo

Or maybe

/app1/trunk
/app2/trunk
/libfoo/trunk

In bzr, you would have a separate branch (groups of branches, in fact)
for 'app1' vs 'app2' vs 'libfoo'.

You can put them all in the same repository, or use separate
repositories. It is just a collection of branches, and they don't have
to share history (that isn't true for all DVCS, but it is true for Bazaar).

So I would do:

bzr init-repo --no-trees bzr+ssh://host/srv/repo
bzr init --create-prefix bzr+ssh://host/srv/repo/app1/trunk
bzr init --create-prefix bzr+ssh://host/srv/repo/app2/trunk
...

Then Liz, Bob and Paul can all push to their respective branches,
without interfering with each other.

And this also gives you an easy way to start doing feature branches.
Liz, for example, can do:

bzr branch bzr+ssh://host/srv/repo/app1/trunk \
 bzr+ssh://host/srv/repo/app1/my-feature

Then when she commits and pushes to the feature branch until she is ready.

Going a step further with bzr, you could use checkouts for each branch.
So instead of having to remember to push, you do:

bzr co bzr+ssh://host/srv/repo/app1/trunk app1
cd app1
Now, because you did a checkout, when they run 'bzr commit' it will
automatically sync their changes up to the server. Just like 'svn commit'.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk21rgQACgkQJdeBCYSNAAOQzgCfRKfr3HturanSsZxFHTEAp6Yz
CPIAn18sVUtxhJruMfxhP0VnZrlI6u2U
=wjlG
-----END PGP SIGNATURE-----

Revision history for this message
jean-michel (jeanmichel-cazaux) said : 		#4

Hi John,

I have experienced a bit with checkout (or bound brancj) and I think it feels like a more natural way to work for me.

The good thing is that you still have the ability to do local commits or go "into the wild" when unbinding your branch.

I think what I missed is that when "unbound" it is probably better to re-bind your branch than push.

Still a bit of experiment, but I feel it can work.

Thanks.
JM

Can you help with this problem?

Provide an answer of your own, or ask jean-michel for more information if necessary.

To post a message you must log in.