BKCVS issue

BKCVS issue

[Aaron Lehmann]

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.

Re: BKCVS issue

[Rob Landley]

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.)

So finally, when you want to know what the code looks like with all the 
changes added, THEN it has to figure out what order the patches have to go in 
to make some sort of sense.  And it has to do that again the next time you 
ask what the tree looks like, because if you add new changes that are based 
on older versions of the tree, they don't go AFTER the most recent changes, 
they get stuck in before and the more recent changes apply to them as well.

Think about how you work:

Original: foo=bar+baz+1
Patch 1 (vs original):  foo=bar-baz+1
Patch 2 (vs original):  foo=bar+fred+1
Result with both changes applied: foo=bar-fred+1

You can come up with the result because you know what the original looked 
like.  The first batch said you should subtract the second variable rather 
than adding it, and the second patch said you should rename the second 
variable "fred".  If you do BOTH, you subtract fred.  But you can't figure 
out what each patch means without looking at the original, not just at the 
results of the previous patch.  This is the fundamental problem with purely a 
linear approach like CVS: you either get patch 2 stomping patch 1, or vice 
versa, or a "it just doesn't apply" error.

Creating a linear set of changes by coming up with a sane order to do it in, 
and adjusting later ones to take earlier ones into account, isn't that hard.  
But when you add more intermediate patches between point A and point B and 
come up with a new list, the new intermediate patches don't naturally go on 
the end, they go in the middle somewhere (since that's the version the 
changes were done against), and they may affect several of the patches after 
them slightly.

This is why the CVS repository has to be recreated from scratch every time.  
It's like the difference between a typewriter and a word processor, when you 
insert in the middle of the paragraph everything after it gets wordwrapped 
differently.  CVS is a typewriter that can only type at the end, and has to 
stick "errata" and correction notices at the end of the book you're writing 
to keep track of any changes you make.  Bitkeeper is more like a word 
processor, where the order changes are made in doesn't matter so much because 
it doesn't have to wordwrap the sucker into its final form until you're done.

Rob

Re: BKCVS issue

[Ben Collins]

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.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: BKCVS issue

[Ben Collins]

> > 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.

That would be pretty rediculous, not to mention impossible for CVS
itself to handle on the client end.

No, for real, bkcvs-2.5 is broken. I already emailed Larry about it. He
acknowledged it, and it's just a matter of time before it's fixed.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: BKCVS issue

[Aaron Lehmann]

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.

I understand that they are built on different models, but I had
thought the bk->cvs translator was somewhat intelligent. I had never
seen all the files in the CVS repository touched until a few days ago.
That's why I brought this up.

Re: BKCVS issue

[Rob Landley]

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

Re: BKCVS issue

[Larry McVoy]

On Mon, Jun 02, 2003 at 05:37:39PM -0700, Aaron Lehmann 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.
> 
> I understand that they are built on different models, but I had
> thought the bk->cvs translator was somewhat intelligent. I had never
> seen all the files in the CVS repository touched until a few days ago.

It is intelligent but it is busted, believe me, I know.  The conversion
happens on my desktop and it thrashes the hell out of the disk when
CVS tags.

We're swamped working on a BK release, that's our first priority.  As soon
as I get a breather I'll get back to the bk2cvs convertoer.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: BKCVS issue

[Jasper Spaans]

On Mon, Jun 02, 2003 at 07:28:59PM -0700, Larry McVoy wrote:

> It is intelligent but it is busted, believe me, I know.  The conversion
> happens on my desktop and it thrashes the hell out of the disk when
> CVS tags.
> 
> We're swamped working on a BK release, that's our first priority.  As soon
> as I get a breather I'll get back to the bk2cvs convertoer.

Just a small pointer which might help, when looking at the cvslog of any
file in the bkcvs repository:

RCS file: /home/cvs/linux-2.5/Makefile,v
Working file: Makefile
head: 1.376
branch:
locks: strict
access list:
symbolic names:
        found: 1.376
        not: 1.376
        command: 1.376
        v2_5_70: 1.356
[...]

So it seems something is b0rken wrt tagging...

Otherwise it's a mighty fine service, thanks a lot for providing it.


Bye,
-- 
Jasper Spaans
http://jsp.vs19.net/contact/

``Got no clue? Too bad for you.''

Re: BKCVS issue

[Larry McVoy]

I'm starting the process of rebuilding these from scratch, my guess is that it
will take a couple more days.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm