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