Using local Bazaar checkouts from a remote Subversion repository
Philip Peitsch
philip.peitsch at gmail.com
Tue Oct 19 23:14:09 BST 2010
Hi Tom,
I've been using bzr-svn with around 15devs for a few months now and found
things not too bad to work with. I've quickly sketched up the workflow we
currently use for interests sake. It has some in common with yours, but
involves a lot less binding and unbinding generally :). Also, we tend to be
pretty "feature-oriented", and as such branch2 tends to be where most of the
commits land, and once everything is working properly again, that feature
will be merged into svn as one largish checkin (retaining the bzr history of
course)
1. do a CHECKOUT of svn into a clean working copy. This is always bound to
svn and is essentially a bzr clone of svn trunk (required for merges later
on)
2. branch the clean svn copy (branch1) into the working / roaming branch
(branch2)
3./4. do all your disconnected commits on branch2 (effectively this is a
feature branch). Updates can be merged or pulled in from svn via branch1
(jump into branch and do bzr up)
5./6. the final change set can be commited back into svn enmasse by jumping
into branch1 and doing a "bzr merge branch2", then a bzr commit to send the
changes to svn
Some other thoughts on your binding/rebinding, it looks like a lot of the
time you are just trying to get in updates. In this case, bzr merge may be
able to do what you want without having to bind & update all the time.
E.g., in branch2, "bzr merge branch1" (dont forget to commit!)
Either way, bzr with svn works quite well. There are a few major bugs to be
wary of if doing multiple developers using bzr on the same svn trunk, but
these will hopefully get some lovin' in the next few months (pretty
pleeeeeeeeaaaaassse). The only major problem we encountered we've adapted a
workflow to avoid... but if you do plan multiple dev's using bzr, let me
know and I can probably give some pointers :)
Cheers,
Philip
On Wed, Oct 20, 2010 at 6:11 AM, Tom Browder <tom.browder at gmail.com> wrote:
> On Tue, Oct 19, 2010 at 11:39, Tom Browder <tom.browder at gmail.com> wrote:
> > On Tue, Oct 19, 2010 at 10:58, John Szakmeister <john at szakmeister.net>
> wrote:
> >> On Tue, Oct 19, 2010 at 11:10 AM, Tom Browder <tom.browder at gmail.com>
> wrote:
> >>> I think I'm in trouble and I know folks here can set me straight again.
> > ...
>
> John, thanks, great blogs. I had seen them early on and didn't know
> enough then to realize the impact of what you said. I also found that
> I was wrong about the binding issue. As a consequence I am starting
> over and including my corrections after the fact as I think I now have
> a working solution.
>
> A recap of my original situation:
>
> repo 1: subversion repo on remote host A (accessed via vpn to company
> network)
>
> note that repo 1 is the master source repository (and it is backed
> up onto multiple disks with svn hotcopy)
>
> repo 2: bzr repo on local network host B, checked out from repo 1
>
> repo 3; bzr repo on local network host C, checked out from repo 2
>
> The fundamental original question was how to update repo 1 from repo 2?
>
> One point I didn't make earlier was that I am the major user of that
> company subversion repo (actually a subversion branch) and no one will
> likely be using it, so I essentially have complete control--i.e.,
> there should be no merge surprises).
>
> After John's questions, I went back and did experiments where I added
> new files in the working trees on all the hosts, changed bindings, and
> generally mucked around to see how I could get it all to work for my
> weird (but I suspect not unheard of) work flow.
>
> My working concept of operations now is this:
>
> 1. Normal operations:
>
> repo 2 is unbound
>
> I work in repo 3 (my laptop, at home) which stays bound to repo 2 on
> my home network and commits are done regularly
>
> repo2 is backed up periodically by pulling into backup repos on host B
> (from System Admin Guide, using bzr as its own backup)
>
> periodically on host B I will rebind repo2 to repo 1, update repo2 and
> commit pending merges to repo 1, then unbind repo 2 again
>
> 2. Mobile operations (work on laptop while away from my network as
> well as the company network):
>
> I work in repo 3 (my laptop, on the road) which normally stays unbound
>
> periodically I will rebind repo3 to repo 1 (a change in parent!),
> update repo3 and commit pending merges to repo 1, then unbind repo 3
>
> 3. Return to home network from a road trip
>
> rebind repo 3 to repo 2, update and commit
>
> bind repo 2 to repo 1, update and commit, unbind repo 2
>
> return to normal operations [1]
>
> From my brief experiments that seems to work okay with no loss of data
> (except probably weird tags and logs). I have done 'bzr version-info'
> on repos 2 and 3 after all changes, additions, commits, updates, and
> merges and gotten the same revision spec in repos 2 and 3.
>
> Now, granted, if there were someone else in the mix things might not be so
> easy.
>
> BTW, one thing I really appreciate about bazaar is the ability to tag
> revisions--I had to leave the subversion developers list in
> frustration a long time ago because I could not convince anyone of the
> utility of tags as CVS uses them rather than the "cheap directory
> copy" of subversion.
>
> Ideas and comments welcome.
>
> Thanks again, John.
>
> Regards,
>
> -Tom
>
>
--
Philip Peitsch
Mob: 0439 810 260
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20101020/87697cae/attachment-0001.htm
More information about the bazaar
mailing list