CVS + in-line BZR

JP Vossen jp at
Wed Jun 27 07:24:45 UTC 2012

I was motivated to write this by Philip Peitsch's response to Daniel 
Carrera's "Migrating from SVN to DVCS" thread [1].  I'm in a similar 
boat, except I'm stuck with CVS instead of SVN.  There are a  bunch of 
reasons for that, some of which are even legitimate.  :-)  I've used CVS 
and SVN for years, so I'm quite comfortable with them, but I've come to 
dislike the way that "commit == publish" quite a lot.  Yes, I know in 
theory you can branch your way around that, but that only works until 
you have to merge the first time...

My solution is in-line BZR.  BZR is quite happy to live inside a CVS 
checkout, though a couple of .cvsignore and .bzrignore files make life a 
little cleaner.  This gives me the best of both worlds at cost of some 
extra steps and overhead (well, and still being stuck with CVS :).

It's been a while since I set it up, but as I recall it was basically:
	cvs get foo
	cd foo
	bzr init
	echo -n ".cvsignore\nCVS" > .bzrignore
	echo '.bzr*' > .cvsignore
	bzr add *
	bzr ci -m'First sync to CVS'

For actual use, it's pretty much:
	cvs up -qn	# for status
	bzr st .	# make sure no uncommitted changes
	bzr ci .	# if needed
	cvs up	# if needed
		# hack, hack, hack
		bzr ci .....  # as needed
	cvs ci	# when ready to be published
	bzr ci . -m'Sync to CVS'

In theory I should be able to push the BZR repo elsewhere so someone 
else can access as needed, but I actually goofed a bit when I set it up, 
and 'bzr join'ed way too much stuff.  More on that in a later thread if 
I can't sort it out.  Anyway I think the way I described it above that 
should work right.

Note the use of the '.' to 'bzr' to make it do "current directory" more 
like CVS.  YMMV.

So I get all the bennies of BZR, especially including the graphical 
qdiff which I love, but I can still push code into the "official" repo 
with trivial effort (though not before its time).  I suppose I should 
write a couple of wrappers for the beginning and end steps but I haven't 
gotten around to it.

One potentially significant downside is that the local BZR repo is just 
that--local--so it's not on the server getting backed up.  I assume that 
could be solved either by pushing BZR elsewhere at the end of the day, 
or by having set up the initial BZR repo as a "centralized" work-flow 
from the get-go.  And that's no different than any of the modern DRCSs 

One thing I do really miss in BZR is the CVS "keywords," because $Id$ is 
a critical part of our work-flow, and $Source$ is very handy too.  In 
the scenario above it isn't that important because CVS will still do 
that, but only for "published" changes.  I'm aware of but that is both buggy [2] and just 
plain did not work for me.  (I tested about 4 months ago and I forget 
the details, I'll try again sometime...)  The nature of my work is 
mostly single config and script files, so there is no build or make or 
any process which can insert 'bzr version-info --custom --template="$Id: 
r{revno} {date} $"'.  :-(

Just wanted to share another success story and possible (ab)use case.
[1] "Migrating from SVN to DVCS" and

[2] A couple of bzr-keywords bugs and

JP Vossen, CISSP            |:::======|
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.

More information about the bazaar mailing list