Equivalent to svn tags?

Matthew D. Fuller fullermd at over-yonder.net
Fri Oct 26 11:34:47 BST 2007


On Thu, Oct 25, 2007 at 12:08:59PM -0400 I heard the voice of
Aaron Bentley, and lo! it spake thus:
> 
> Well, I guess I wouldn't stand in the way of such an approach, but
> I'd definitely want to be able to opt out of it.

Oh, I don't at all suggest this should supplant our current flow; I
LIKE our current flow.  Don't mistake my "this is a capability we
really should have" claim for a "this capability should supercede our
current caps".  I tend to like the idea of having it happen via a
pseudo-branch of some sort, but that's details.


> > But I'm not necessarily interested in particular revisions.  I'm
> > interested in branches.
> 
> Could you say a bit more about why, then?

Well, that's what the rest of the mail about FreeBSD practices was
aimed at.  Did I go off into the weeds without reaching my
destination?


> >> bzr merge ../branch-0.3.0
> >> # Revert any 0.3.0 specific changes, like the version properties
> >> bzr commit -m "Merging branch-0.3.0 into trunk"
> 
> I strongly recommend doing that irrespective of tagging.  So for me,
> it wouldn't be "just to make a revision visible", thus not a hack.

See, I don't understand why.  It doesn't make sense to me.  Those revs
don't seem to me to _belong_ on the trunk.  0.3.0 isn't an ancestor of
the dev head (they probably share a LOT of common ancestors, and there
are probably relatively fewer revs along the 0.3.0 path that aren't
ancestors of head, but they're still diverged), so I don't know any
reason it SHOULD be in that ancestry.  Feature branches are intended
to diverge, accomplish something, and come back home older and wiser,
but release or release-series branches are intended to diverge and go
their own way.  I can't conceive of any purpose in grafting them back
onto the trunk when they've run their course OTHER than as a hacky
"make these revs accessible to somebody with only a copy of trunk".


> What about nested trees?
> http://code.aaronbentley.com/bzr/bzrrepo/nested-trees
> 
> I think this qualifies as public, because other people have used it.
> And it's certainly long-lived.

Well, *I* didn't know about it, so how public could it be?   ;)

Is there some significant percentage of the non-release user base
using it instead of bzr.dev (or using a merger of the two, anyway)?
That's roughly the meaning I was aiming at.


> > I'm confident that in that sort of community, walking up and
> > offering a VCS by saying "Look, you have to individually and
> > explicitly name every upstream branch you want to track"
> 
> Who's saying that?  It's incredibly easy to mirror
> http://bazaar-vcs.org/bzr/.  It's just rsync instead of cvsup.

That carries with it a large number of problems.  Most importantly, it
means the repo structure has to be the same on both sides; you can
only mirror a whole repo (well, or multiple repos), which I'd want to
avoid.  It means you can't use that repo locally, so any branches
other than those you're mirroring would mean you'd be duplicating all
the history (ignorable maybe with a 10 meg history, but not when it
gets to a couple gig).  It also means you're lock-step with the remote
format etc (which is probably rarely a problem in practice, but it's
still an unnecessary constraint, and means biiiig transfers when that
format changes).

And don't forget speed; rsync sure beats bzr over http on a knit repo,
but it would lose to a sufficiently smart smart server.  For that
matter, I suspect it would lose hard even against bzr today with large
pack repos; repacking means rsync would keep having to delete and
re-transfer data, and when you start talking multi-gig repos, that
gets REALLY expensive.  (This of course isn't intended as a negative
mark against packs.  bzr should use bzr-friendly formats, not
rsync-friendly formats)



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.



More information about the bazaar mailing list