Evaluating Bazaar in a CVS environment.

[John Arbash Meinel]

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

Andy Walker wrote:
| I would like to evaluate Bazaar in the development environment where I
work.
|
| We are currently a CVS shop, and have a massive centralized project
managed by
| CVS.  The plan is to move to something better soon, and I would like
to evaluate
| Bazaar for this and collect my experiences for review.
|
| I would like to run Bazaar to manage my workflow on a bug-by-bug basis
for now,
| but I'm having some difficulty with the terminology and how to set
this up.
| Perhaps I am improperly understanding when branches should be used and
when they
| shouldn't.
|
| Ideally, I would be able to create a branch for each bug that I'm
working on in
| order to edit the files with impunity.  The catch is that this source
tree is
| really large, and I don't want to be copying the whole thing each time
I start
| to work on a bug.  Ideally, I'd be able to have a branch that only
contains the
| modified files that relate to a particular task or bug, and then, upon
| completing my work, merge that branch to the "trunk" CVS-controlled
directory
| and issue 'cvs up'.
|
| Based on my current understanding, I should create a "work" or "code"
directory,
| and issue 'bzr init-repo --no-trees" in that directory.  Then I create a
| directory for this main work project called HEAD, and copy the highest
level of
| the CVS tree that I will be working on into that directory.  Then I
'bzr init'
| HEAD, 'bzr add' and 'bzr commit' the initial revision.
|
| From this point, I'm a little hazy.  I know that I can cd to "work"
and 'bzr
| branch HEAD bug-1234', and it will create a directory representing the new
| branch.  I know I can issue a 'bzr checkout' inside this directory,
but I cannot
| target that checkout to single files, so it seems as if I need to copy the
| entire source tree in order to create a branch that I can work on.
|
| This is, of course, only my current understanding, and is probably off
by a
| great deal.
|
| Currently, I use a homegrown piece of software that simply creates a
directory
| on a task-by-task basis and then copies individual files from HEAD
into that
| directory (along with CVS files) as I specify them.  These files can
then be
| 'cvs up'ed to get any updates to them or published directly to test my
changes.
|
| I would like to replace the niche this tool occupies (bug/task-based
branching)
| with Bazaar.  Thoughts?
|

There are a few things to consider when switching to bzr.

1) Do you really want to check out the whole thing at once? Bazaar
generally works with each branch as a logical "project". I know usually
for CVS/SVN you might have multiple projects all grouped together. If
you have logical groupings, it is almost always a better fit to Bazaar
(and really any DVCS) to split it up.

2) If your working tree is large, and you want lots of branches, you
probably want to look into using a lightweight checkout, and a tree-less
repository, which I'll describe more later.

3) Your above workflow will probably work, except I think the "bzr init"
will create a branch without a working tree (because you declared
- --no-trees in the containing repository.) So you would need an extra
"bzr co" step.

I use a similar layout, which works fairly well. I personally like to
have couple working trees active (mostly HEAD and 'current'). So this is
how I would do it.


a) bzr init-repo --no-trees repo
b) cvs -d.... co cvspath HEAD
c) cd HEAD
d) bzr init; bzr co .
# tell bzr to create a working directory here as well
e) bzr ignore CVS
# Ignore all CVS directories in the whole tree
f) bzr add
g) bzr commit -m "Initial import of HEAD"

Now, you could do the initial import with a converter, to extract all of
the history. That is generally up to you. If you don't need the history,
I would skip it.
So at this point, you have a pristine CVS tree, and a bzr checkout
co-located. I would then branch this off, so that you can get your own
work done.

h) cd ..; bzr branch HEAD current-feature

But notice that there are no working files in 'current-feature'. Just a
'.bzr' directory. That is what we call a "treeless branch". Branches
keep track of the last committed revision, etc.
But we want to be able to work on the files. (like we have in HEAD).
There are two schools of thought here. One is to create a WT underneath
"repo" and the other is to have it outside. I personally have it under
repo as it makes paths shorter when I need to reference a different branch.

i) bzr co --lightweight current-feature work

Now you have a place 'repo/work' which you can edit your files. Because
it is a lightweight checkout, any commits you make will update the
'current-feature' branch.

You can keep working here for a while. At some point, people will make
changes in CVS that you'll want, so we pull those into bzr with:

j) cd ../HEAD
k) cvs update
l) bzr commit -m "Updating to the latest version in cvs."

And now you can chose to propagate those changes into your feature
branch or not. You may not be ready for them, but if you are, let's
merge them in.

m) cd ../work
n) bzr merge ../HEAD

At this point, the changes are in your "working tree" but have not been
committed. Look them over, resolve any conflicts, etc.

o) bzr commit -m "Merging in the latest changes from HEAD"

And then you can continue to work on your feature branch. Eventually
you'll want to merge those changes back into CVS, so everyone else can
get them. Do that with:

p) cd HEAD
You should always make sure you are at the latest cvs tip, before doing
this next step.
q) cvs update; if changes => bzr commit -m "updates from CVS"
r) bzr merge ../work, or bzr merge ../specific-feature
If you reference your working tree, it will figure out what branch to
merge, but you can also just reference the branch directly.

At this point, cvs should notice that some files are modified.
Generally, I would make *CVS* the official location for your HEAD
branch. So I would do

s) cvs commit -m "Bring in specific-feature changes"; bzr commit -m
"Bring in specific-feature changes".

Now, you also will probably end up working on multiple feature branches,
and might have multiple ones that aren't ready to be merged yet. So to
create a new one and start working on it:

t) cd ..
u) bzr branch HEAD new-feature
v) cd work
w) bzr switch ../new-feature

Now your working location is pointing at 'new-feature', you can make
your changes, commit, merge what you need to, etc.
If you need to switch back to an old feature

y) bzr status

If there are changes, you need to decide if you want to commit them in
the branch you are in, or if they belong to the feature branch you are
going to be switching to. If the former, do "bzr commit" and then "bzr
switch", else just do "bzr switch".


Does that give you the basic idea?

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

iEYEARECAAYFAkhlOiUACgkQJdeBCYSNAAOpPQCgrzkUrk1VaStaOhfPeExUDqSl
7ksAn0pLuZ0HClhfH5pyjzrOHVNOAGom
=HXG8
-----END PGP SIGNATURE-----