Bazaar

bzr and two writers

Asked by Chris Perry

I'm newish to bzr. For the Ubuntu desktop help we work like this. The master branch (ubuntu-docs) is of course on Launchpad. Each writer has a local copy of the master branch. The writer pushes changes to a personal branch (on Launchpad) to be checked and when the changes are approved pushes the changes (bzr push lp:ubuntu-docs) to the master copy.

Will this method work when two or more writers are working at the same time? For example, writer A may start a long job. Before writer A has finished writer B wants to make a quick change that takes five minutes and push to the master branch. Will that work OK with bzr? I imagine it's the kind of thing that bzr is designed for. But I want to double check!

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Vincent Ladeuil
Solved:
Last query:
Last reply:
Revision history for this message
Vincent Ladeuil (vila) said : 		#1

> I'm newish to bzr. For the Ubuntu desktop help we work like this.

Hi !

> The master branch (ubuntu-docs) is of course on Launchpad.

Ok.

> Each writer has a local copy of the master branch.

We just say bingo^H^H^H^H^H a branch, sometimes a local branch.

> The writer pushes changes to a personal branch (on Launchpad) to be checked and when the changes are approved

Right, it looks like you're using launchpad merge proposals for that: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/trunk

> pushes the changes (bzr push lp:ubuntu-docs)

Yes, after merging the proposal locally.

> to the master copy.

So lp:ubuntu-docs is what launchpad refers to as the 'Development focus', it's an alias for your https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/trunk . This is the branch that is authoritative for the project. It's often referred to as "the trunk" and indeed that's your case ;-)

The most common workflow is:
- a local branch of the master,
- a human or a bot merge the approved changes (a branch from an approved proposal)
- the change is committed (with a summary for the proposal) and pushed to the trunk

And this seems to match exactly what you did for revno 597 (Snap documentation in 17.04; LP: #1658785)

> Will this method work when two or more writers are working at the same time? For example, writer A may start a long job. Before writer A has finished writer B wants to make a quick change that takes five minutes and push to the master branch.

If conflicts appear between A branch and the trunk updated with B's work, the local merge will show them.

You can fix them or revert the merge and ask A to resolve the conflicts (he will merge trunk locally and push again to update the proposal).

> Will that work OK with bzr?

Both workflows work with bzr and launchpad, yes.

> I imagine it's the kind of thing that bzr is designed for. But I want to double check!

Hope this helps.

Revision history for this message
Chris Perry (clissold345) said : 		#2

Hi Vincent

Thanks for your reply. Can I check I've understood? In the case I've imagined, conflicts will occur if writer A changes one of the files that writer B changed? Is that correct?

I was told to do bzr pull (to pull any changes since my last pull), then bzr commit ... (to create a revision), then bzr push ... (to push to a personal branch to get a draft reviewed). If writer A changes one of the files that B changed and then executes those commands in that order, which if any of them will give an error message flagging the conflict? Or perhaps the conflict is only flagged when writer A attempts bzr push lp:ubuntu-docs?

I hope I've described that clearly.

Regards, Chris.

Revision history for this message
Best Vincent Ladeuil (vila) said : 		#3

> Thanks for your reply. Can I check I've understood? In the case I've imagined, conflicts will occur if writer A changes one of the files that writer B changed? Is that correct?

Yes. But the best (only ?) way to understand is to run through it.

You can create local branches and experiment. Call them 'trunk', 'A' and 'B' ?

Also, try installing the qbzr plugin and try 'bzr qlog' in lour local branch or even do 'bzr qlog trunk A B' to visualize your branches.

> I was told to do bzr pull (to pull any changes since my last pull), then bzr commit ... (to create a revision), then bzr push ... (to push to a personal branch to get a draft reviewed).

That's all correct.

But you'll start encountering conflicts when A commit locally, B commit locally and push, A attempt to push (and get a 'branches have diverged' message requiring A to merge), that's when you can get conflicts.

Revision history for this message
Chris Perry (clissold345) said : 		#4

Hi Vincent, thanks for answering my extra questions. I appreciate your help. Yes, you're right: the best way for me to understand it is to do some tests.

Revision history for this message
Chris Perry (clissold345) said : 		#5

Thanks Vincent Ladeuil, that solved my question.

Revision history for this message
rosetta22 (rosetta22) said : 		#6

You got me interested. As a writer who has been working for a company https://ibwritingservice.com/ for several years. I understand what difficulties can be in the process of completing assignments for students. But this is all nonsense when you consider the fact that a good writer definitely loves his job and enjoys the writing process.