Update: Re: bzr 0.6 commit problem: parent_id {blah} not in inventory

[John Whitley]

On Nov 3, 2005, at 4:27 PM, Michael Ellerman wrote:
> For the record, I'm not suggesting that partial commits shouldn't  
> be allowed,
> I just think they shouldn't be the default. You can emulate the
> commit-in-this-sub-tree behaviour with "bzr commit ." which is  
> pretty easy.
> Although as John (I think) said, there might be some bugs lurking  
> in there.

I'll suggest that the real problem is that Andrew (and others) have  
come across a "submarine use case".  That use case is one of several  
semi-dependent modules or projects living within the same source  
control tree.  This was exactly the model that a *very* large  
Perforce repository that I once worked with used.  Logically, the  
repository was broken up into many projects (deliniated by a hiearchy  
which occupied the first few levels of the repository path), which  
may or may not have had dependency relationships between them.  But  
the revision numbers were global across all developers for all of  
these sub-projects.  In practice, developers would check out one or  
more packages into a local workspace for a particular development  
effort.  Related changes could span these projects and be checked in  
as an atomic commit.  For example, imagine related changes to:
   1) a networked application client library
   2) networked application server code
   3) a shared library that needs extension work for the project

As a historical matter, this codebase had started off as a single  
monolithic unit which had grown beyond the bounds of reason and  
eventually been refactored into independent pieces over the years.   
Nevertheless, some dependencies (due to use of various shared  
framework code and/or client libraries) remained.  At the time I was  
there, the revision numbers had no global dependency meaning anymore  
outside of a single project -- i.e. the model was the same as  
multiple independent bzr branches.

An entirely separate package management layer was built on top of all  
this to keep track of version dependencies between released versions  
of various teams' packages.  Referring to the example I provided  
above, this package versioning layer prevented changes in shared  
libraries or client libraries from "automatically" propagating to  
other project codebases.  A team had to explicitly request a version  
update of their package dependencies, then build and test their app  
with the updates before a release.

Hope all that wasn't too far afield. ;-) I thought telling that story  
might help spark good ideas for bzr's present and future.

-- John