Is there a better structure for this local-Bzr-Team, upstream Svn branch, situation?
Doug Lee
dgl at dlee.org
Thu Sep 9 21:58:57 BST 2010
I'm working on a team that needs to make local changes to a Subversion
branch. The Subversion tree is very large, but our changes are
scattered throughout it. So far, our strategy has been to each check
out from Svn, then through a bit of folder-moving trickery and such,
cause a Bazaar branch to coincide with it (i.e., the root of the
checkout contains both .svn and .bzr folders). Then we just track in
Bazaar the files we change or add ourselves (happily, we need not
remove any of the Svn files). We occasionally do `svn update' to keep
in sync with upstream Svn changes, and `bzr commit' any of those that
touch the files we're tracking in Bazaar. The final `svn commit' is
then a simple matter. We have a locally shared Bazaar branch, to
which we all bind, so that our changes propagate internally.
But modern Bazaar versions are getting smart enough to handle Svn
checkouts directly, and a coworker of mine just about made a
nightmarish main-Svn-branch commit by mistake via "bzr commit" one
day. This email is prompted by my realization that my current plan
starts collapsing somewhere after Bzr 2.1.2.
As one more bit of background, the plan is, by enforcement of
Svn-upstream administration, that we make our final commits for
updates as single commits, complete with a commit template we must
fill out. They would not want a blast of little commits, such as
with `bzr rebase' / `bzr push' sent up Svn. Hence the "final Svn commit"
I mentioned above.
So... I'm trying to work out the best model for this situation. I
envision each team member having a local Bazaar branch of the full
Svn branch, and there being a shared team Bazaar branch, which I'll
call proj.local here, for us to use to send our updates back and
forth among the team members without sending anything to Svn. But
I'm not sure if this can work, and exactly how. Here's my best
guess, but I'm asking for help catching flaws and filling in a
couple of holes before I make a huge mess:
1. I pull down a full Bazaar copy of the Svn branch with `bzr get'.
2. I push that to a locally central location I'm nicknaming
proj.local, then I bind to that.
3. I tell everyone else on the team to make two bookmarks:
proj.local and proj.svn for the Svn branch.
4. I also tell everyone on the team to do `bzr co bm:proj.local',
so they will be bound to that.
5. Anyone at any time can do `bzr merge --pull bm:proj.svn' to
bring down the up-to-date non-local changes, and because of the
proj.local bind, we will all be kept aware of this (but what happens
if member 1 pulls down updates, then I do it and there are two more,
but I didn't yet go to proj.local for local (and member 1's remote)
updates??)
6. When one of us has to commit to the rest of the team, we do
`bzr rebase' (or, if the member prefers, `bzr update/merge') against
bm:proj.local if necessary, then `bzr commit' which will automatically
go to proj.local. (I have it set up so this will send out an email
as well.)
7. When it's finally time to update Svn, one of us syncs first with
proj.local, then does the usual `bzr merge --pull bm:proj.svn', and
finally sends the required single commit up to Svn (help needed on how
to do that).
Thanks for any help. Absent better ideas, I'm currently telling
people to use Bzr 2.1.2 or older for this project.
--
Doug Lee dgl at dlee.org http://www.dlee.org
SSB BART Group doug.lee at ssbbartgroup.com http://www.ssbbartgroup.com
The very smart may feel they have nothing to learn from anyone;
The very wise will find something to learn from everyone. (7/14/01)
More information about the bazaar
mailing list