BKCVS issue
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.
Quoted 5 lines · 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.
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
Quoted 10 lines · Rob Landley
Quoted 5 lines · 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.
CVS thinks of changes as having been applied in a certain order, with each cange applying to the result of previous changes.
Quoted 6 lines
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.
Signature · 4 lines
Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Quoted 18 lines · Ben Collins
Quoted 10 lines · Rob Landley
Quoted 5 lines · 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.
CVS thinks of changes as having been applied in a certain order, with each cange applying to the result of previous changes.
Quoted 6 lines
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.)
Quoted 6 lines
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
Quoted 7 lines
Quoted 2 lines
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.
Signature · 4 lines
Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Quoted 9 lines · Rob Landley
Quoted 5 lines · 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.
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.
Quoted 6 lines · Aaron Lehmann
Quoted 5 lines · Rob Landley
Quoted 4 lines · 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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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->cvstranslator 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.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · Larry McVoy
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,
Signature · 4 lines
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.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm