Fwd: Re: Branching with a Central Repository

[Neil Martinsen-Burrell]

[This should have gone to the list as well.  My bad.]

-Neil

-------- Original Message --------
Subject: Re: Branching with a Central Repository
Date: Tue, 06 Oct 2009 10:36:43 -0500
From: Neil Martinsen-Burrell <nmb at wartburg.edu>
To: A. S. Budden <abudden at gmail.com>

On 2009-10-06 07:53 , A. S. Budden wrote:
> We are currently looking to move over to Bazaar at my workplace.  Due
> to the way work is backed up and shared, we will be using the central
> repository approach [1] mostly, such that everyone uses checkout to
> get projects.  The initial plan for a repository layout (no working
> copies) is:
>
>      root\ProjectGroup\Project1
>      root\ProjectGroup\Project2
>
> These will be the trunk of the project.  I had thought that if we
> create branches (we don't really do this at all at the moment), the
> new branches will be:
>
>      root\ProjectGroup\Project1\feature-gui
>      root\ProjectGroup\Project1\feature-magic

In distributed version control tools, I think it is best to think of all
branches, including the trunk as peers.  So, I would use a layout like

        root\ProjectGroup\Project1\trunk
        root\ProjectGroup\Project1\feature-gui
        root\ProjectGroup\Project1\feature-magic
        ...

My experience with this is that it works best to have the Project1
directory as a shared repository (i.e. on the server ``cd
root\ProjectGroup; bzr init-repo --no-trees Project1``).  You can put
the shared repository up in the root or ProjectGroup directories, but I
think that it is best to keep the shared repository at the level where
related branches will be made.

> However, I'm not clear from the documentation how to actually work
> with this.  We have a very thorough backup régime on the repository
> and are very keen to use this as the commit destination.  The closest
> thing I've come up with (which seems especially convoluted in the
> GUIs, which most of my colleagues will use) is something like (I may
> have made mistakes here):
>
>      # Get the project
>      bzr co f:\root\ProjectGroup\Project1
>      cd Project1

If you want to do all of your local development in a single working
tree, switching between branches stored on the server, then I would do

        bzr co f:\root\ProjectGroup\Project1\trunk work
        cd work

>      # Do some editing (e.g. go to revision 10)
>      bzr ci -m "Done some editing"
>
>      # Now branch: it'd be nicer to just do
>      # "bzr branch feature-gui" and automatically
>      # handle the relationship to the current checkout
>      bzr branch f:\root\ProjectGroup\Project1
> f:\root\ProjectGroup\Project1\feature-gui
>
>      # Bind to the new feature
>      bzr bind f:\root\ProjectGroup\Project1\feature-gui

bzr branch now has a --switch option that will switch the current
checkout to the newly created branch so the two commands above are
collapsed into

        bzr branch --switch f:\root\ProjectGroup\Project1\trunk
f:\root\ProjectGroup\Project1\feature-gui


>      # Do some editing (e.g. go to revision 11)
>      bzr ci -m "Added GUI template files"
>      # Do some more editing (e.g. go to revision 12)
>      bzr ci -m "Added GUI"
>
>      # Now we need to merge it back into the mainline
>      # (so we get 10.1.2 or whatever [2]) and switch back.
>      # How do we do this cleanly?
>
>      # Guess (this is nasty):
>
>      # Bind to the original project path (this could get messy as
>      # we've got the changes already made!)
>      bzr bind f:\root\ProjectGroup\Project1\
>      # Merge in the changes
>      bzr merge f:\root\ProjectGroup\Project1\feature-gui

That's exactly right, except you forgot the need to commit after your merge.

        bzr switch f:\root\ProjectGroup\Project1\trunk
        bzr merge f:\root\ProjectGroup\Project1\feature-gui
        # resolve conflicts and test
        bzr ci -m 'merged in the GUI'

> Is there a better way to do this?  I've been reading the
> documentation, but most of the branching/merging discussion focuses on
> the distributed development workflow.

I think that one of the best ways to learn Bazaar and its workflows is
to work out example situations to see what happens.  Here's what I had
while I was writing this email (lightly edited so I look smarter).

nmb at guttle[~/tmp]$ bzr init-repo --no-trees Project1
Shared repository (format: 2a)
Location:
   shared repository: Project1
nmb at guttle[~/tmp]$ bzr init Project1/trunk
Created a repository branch (format: 2a)
Using shared repository: /Users/nmb/tmp/Project1/
nmb at guttle[~/tmp]$ bzr co Project1/trunk work
nmb at guttle[~/tmp]$ cd work
nmb at guttle[~/tmp/work]$ bzr info
Checkout (format: 2a)
Location:
        checkout root: .
   checkout of branch: /Users/nmb/tmp/Project1/trunk
nmb at guttle[~/tmp/work]$ echo "contents" > a
nmb at guttle[~/tmp/work]$ bzr ci -m 'first revision'
nmb at guttle[~/tmp/work]$ bzr add
adding a
nmb at guttle[~/tmp/work]$ bzr ci -m 'first revision'
Committing to: /Users/nmb/tmp/Project1/trunk/

added a
Committed revision 1.
nmb at guttle[~/tmp/work]$ bzr branch --switch ~/tmp/Project1/trunk
~/tmp/Project1/feature-gui
Branched 1 revision(s).
Tree is up to date at revision 1.
Switched to branch: /Users/nmb/tmp/Project1/feature-gui/
nmb at guttle[~/tmp/work]$ bzr info
Checkout (format: 2a)
Location:
        checkout root: .
   checkout of branch: /Users/nmb/tmp/Project1/feature-gui
nmb at guttle[~/tmp/work]$ echo "more stuff" >> a
nmb at guttle[~/tmp/work]$ bzr ci -m 'added stuff to branch'
Committing to: /Users/nmb/tmp/Project1/feature-gui/
modified a
Committed revision 2.
nmb at guttle[~/tmp/work]$ bzr switch ~/tmp/Project1/trunk
Updated to revision 1.

Switched to branch: /Users/nmb/tmp/Project1/trunk/
nmb at guttle[~/tmp/work]$ bzr merge ~/tmp/Project1/feature-gui
  M  a

All changes applied successfully.

nmb at guttle[~/tmp/work]$ bzr st
modified:
   a
pending merge tips: (use -v to see all merge revisions)
   Neil Martinsen-Bu... 2009-10-06 added stuff to branch
nmb at guttle[~/tmp/work]$ bzr ci -m 'merged the feature branch'
Committing to: /Users/nmb/tmp/Project1/trunk/

modified a
Committed revision 2.