Re: BitKeeper open-sourced

[Larry McVoy <lm%mcvoy.com@localhost>]

> I agree git is not a model one should base one's worldview on, and
> git's notion of what it calls "branches" is strange; however, in most
> other systems there's a notion of a branch that's a distinguished
> subgraph of the overall commit graph and you can have more than one at
> a time in the same repository, tell them apart, and so forth.

Correct.  And other than implementation details, how is a series of
clones, each containing the common history and the branch specific
history, not exactly what you are describing?

From a math/graph point of view, the clones are branches.  Each clone
contains the common history up until the branch point (which was the
creation of the clone) and the branch specific information (any commits
after the clone).

You can of course quibble about the implementation, but from a math
point of view it seems impossible to claim that a clone is not a branch.

> Mercurial started out with the idea they could use repository clones
> for branching, but quickly found it wasn't satisfactory and added real
> ("named") branches.

We have some internal work on named branches.  Once you agree that
clones are mathematically the same as branches we can move on to why
clones are suboptimal (they are, trust me, we know).

> There are a number of issues that can arise when trying to use clones
> for branches, but the most serious for a large project with a
> globe-spanning infrastructure are probably (1) management and (2)
> accidentally pushing changesets to the wrong repo.

So you have an uphill battle to convince me that management is a problem.
We've been using this model for 18 years, the processor you are using 
to read this email was made with the verilog in BK, the management just
isn't a real issue.  Or it's not an issue that you have explained enough
to get me to agree there is a problem.  There could be but lots of people
have used this model happily.

As for accidentally pushing changesets to the wrong repo how is that any
different than pushing to the wrong branch?  In both cases you are saying
"push this stuff to there".

BK has some basic support to make sure that you don't hit that problem.
It works if you have a series of branches where you want the changes
to flow forward but not backwards.  As in you have a bugfix branch
that is always ready to be released, a "next" branch that is your
next minor release, a "dev" branch that is your next .0 release.
Look at "bk help level", you can set a repo level and it won't accept
changes from a higher level repo.  The level propogates on clone.

If that sort of thing was what you wanted but it isn't general enough
we could look at fixing that.  And there are other ways to do this,
it can be done with triggers (aka hooks).

> While it's easy to create a private branch, if you want to make a
> project-level branch you have to create a canonical repo for the new
> branch, name it somehow, make it downloadable, tell people where to
> get it... all of which requires a lot of manual administration that
> disappears given native support for branches. (E.g. in Mercurial all
> you have to do to create a new project level branch is "hg branch
> newstuff", hg commit, hg push)

Except that people need to know where that repo is.  It's
hg://somemachine/somerepo/<some branch>
something like that, right?  And you have to tell people the url.

It's the same process that you'd use for BK.  Use this URL for 
the whatever-branch.

> There are things you can do to make it harder to push changes to the
> wrong repo (e.g. use something like a blacklist extension to ban the
> base changeset of each branch from each other branch and from the
> trunk) but this also requires manual administration.

See the bk level stuff.  

> That said, I'm speaking from experience with Mercurial. I don't know
> how BK works internally.

I, or any of the other devs, would be happy to answer any questions.

In exchange, I'd like to understand what you need.  You guys are still
on CVS if I understand correctly.  Which is painful in various ways.
You looked at git and said no: why?
You looked at hg and said no: why?
If we understood those things we might have a better feel for what you
need.  And we'd like to help, for obvious reasons.  If you get us to 
understand your needs and we can't help, we'll tell you that we can't
help.

I could see a friendly path forward being we learn more about your needs.
We, both your team and ours, focus in on the must-haves (if we don't
have that focus it turns into a bike shed comedy and none of us have
time for that).  If after enough of that it seems like it's possible
we could help then we go off and import enough of your CVS history that
you can play and see some of the benefits and get excited.  If you do,
then we work together to get the rest imported.

My gut feel is that unless we do a pile of import work this is all noise.
Before we do that, we should be more on the same page.

What's your take?

--lm

P.S.  BTW - if any of your people want to play around with importing we can
put some nice hardware on the net and give them logins.  4.5ghz (overclocked
but stable) 6 core/12 thread cpus, 64GB of ram, 800GB of Intel SSD in PCIe
slots striped for better perf (I was doing some import and so 400MB/sec to
the disks), etc.  Just let me know.