Recording branch points

[Robert Collins]

On Wed, 2006-09-20 at 23:08 +0200, David Allouche wrote:
> Aaron Bentley wrote:
> > John Arbash Meinel wrote:
> >>>> There is currently a model mismatch between bzr and Launchpad: the bzr
> >>>> model really only knows about revisions, while Launchpad has an explicit
> >>>> branch model.
> > 
> > I don't think that's a good way of distinguishing the models.  bzr most
> > definitely has branches.  It's just that creating a new branch
> > essentially clones the original.
> 
> Did not we have this discussion already?
> 
> Maybe it is semantic nitpicking, but my position is that bzr branches
> are not part of its fundamental model, they are part of higher level
> models of user interface and storage implementation. The fact that a bzr
> branch is essentially a revision-id plus some ancillary data (pointer to
> a repository, branch nick, parent branch, etc.) supports that position.

bzr branches are a fundamental part of its model; they are not a
fundamental part of the 'revision storage' layer within bzr. I think its
important that we dont confuse 'revision storage' with 'bzr fundamental
model' - the core bzr model is designed to promote a lovable user
experience, and having branches manipulable with only regular unix tools
is part of that joy.

> There is a fundamental difference between that and more centralized
> branch models like Subversion, GNU Arch (there, the centralized aspect
> was delegated to the domain name system, but it was still present in the
> core model), Launchpad and even the hard cold world of physical hard
> disks. In those models, a branch can be only at one "place" at a time.
> 
> I consider this a very interesting philosophical discussion, but I guess
> we can agree on the practicalities without agreeing on this.

FWIW I agree we have fundamental differences between bzr and svn/arch
etc. The most pithy statement I have for the difference is to say that
the value of a bzr branch is not defined by location, rather by content.
This is not the same as saying that branches are defined are defined by
value rather than location. That is, two bzr branches with the same tip
revision are only considered to be the same branch when they are at the
same URL. However, two branches at different urls can have the same
value, even though user preferences etc will be different.


> > I think that isn't required for launchpad to know what revisions are new
> > to a branch.  Wouldn't a 'branch-point' marker be enough?
> 
> A branch-point marker would be plenty good enough for Launchpad.
> 
> But I would be very interested in ways to make this provide value to
> simple bzr users. Because otherwise there is little incentive to stick
> to practices that record meaningful branch points.

Right now there is enough information to infer branch points very
reliably using the branch nick field. By default it should do a plenty
accurate job, with only occasional false positives (user renames a
branch), and false negatives (user repurposes an existing directory for
another task, while branching it to somewhere else to continue
development on the old branch).

I'd want to see a pretty thorough analysis of the failure modes that
will leak up to the UI before I would be convinced of the safety and
tastefulness of adding a branch point marker per se.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061016/a1afb609/attachment.pgp