CVS + in-line BZR
JP Vossen
jp at jpsdomain.org
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
Loop:
# 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
anyway...
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
https://launchpad.net/bzr-keywords 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.
JP
______________________________
[1] "Migrating from SVN to DVCS"
https://lists.ubuntu.com/archives/bazaar/2012q2/074900.html and
https://lists.ubuntu.com/archives/bazaar/2012q2/074893.html
[2] A couple of bzr-keywords bugs
https://bugs.launchpad.net/bzr-keywords/+bug/408841 and
https://bugs.launchpad.net/bzr-keywords/+bug/697260
----------------------------|:::======|-------------------------------
JP Vossen, CISSP |:::======| http://bashcookbook.com/
My Account, My Opinions |=========| http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"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