Re: BKCVS issue

[Rob Landley <rob@landley.net>]

On Monday 02 June 2003 19:39, Ben Collins wrote:
> On Mon, Jun 02, 2003 at 07:37:02PM -0400, Rob Landley wrote:
> > On Monday 02 June 2003 17:14, Aaron Lehmann wrote:
> > > For the past few days, it seems like every time something changes in
> > > BK, the bkcvs repository has all of its files touched. At least, all
> > > files in the repository have a P preceding their names on a cvs up.
> > >
> > > It's not intolerable, but I was wondering if anyone's aware of it.
> >
> > CVS thinks of changes as having been applied in a certain order, with
> > each cange applying to the result of previous changes.
> >
> > Bitkeeper does not.  Each change applies to a historical version of the
> > tree, and when it gets two sets of changes based on the same historical
> > tree neither one of them goes "before" the other, they both apply to the
> > old tree. (This isn't a linear process, it's lots and lots of branches. 
> > Conflicts don't come up at this point, think quantum indeterminacy and
> > the trousers of time and all that.)
>
> bkcvs doesn't do this. It can't. There's no way for CVS to represent
> what BK does. bkcvs is instead linear, but some commits are groups of
> changesets instead of single changesets.
>
> The problem is that bkcvs 2.5 is broken. Larry has said he will fix it,
> time permitting.

I was under the impression that the problem in bkcvs was a design issue: it 
converted a BK repository to a CVS repository by creating a fresh CVS 
repository from scratch each time.  It didn't modify an existing CVS 
repository, which would be a bit more work.

It's not impossible, I suppose.  If you can feed bk the tree version that the 
old CVS was created against, there's existing logic to create create a 
gnu-style patch that gets the tree from point B to point C.  The only problem 
with creating a series of CVS entries instead of a patch is keeping the 
changes seperate when you do it...

Dunno how big a problem that is, I haven't looked at the BK source.  I'd like 
to keep my options open if I decide to work on subversion or some such in the 
future. :)

Rob