Problems using new Linux-2.4 bitkeeper repository.
How do those of us who've been using the
http://gkernel.bitkeeper.net/marcelo-2.4
for development resync against the kernel24.bkbits.net tree? It looks like the changes from 2.4.18-pre8 onwards all have different patch IDs in the new tree; so when I try to do a pull from my current repository I get tons of conflicts, if I try to do a receive of just the patch set I get a resync error:
takepatch: can't find parent ID
[email protected]|ChangeSet|20020225230300|18879
in RESYNC/SCCS/s.ChangeSet
The thought of taking everything back to the common ancestor and then trying to apply the changes one at a time and adding the change logs by hand isn't that appealing (I have 3 2.4 repositories, some with upwards of 10 additional change sets in them).
James
Quoted 6 lines · James Bottomley
How do those of us who've been using the
http://gkernel.bitkeeper.net/marcelo-2.4
for development resync against the kernel24.bkbits.net tree?
Through the magic of BK :)
Just do a 'bk pull' on my marcelo-2.4 tree. Since it is based on the original linux-2.4 tree just like Marcelo's tree, I was able to merge from my 2.4 line to his 2.4 line.
Jeff
Quoted 5 lines · [email protected] said:
Through the magic of BK :)
Just do a 'bk pull' on my marcelo-2.4 tree. Since it is based on the original linux-2.4 tree just like Marcelo's tree, I was able to merge from my 2.4 line to his 2.4 line.
Well, I tried this, but it just gave me a slew of initial rename conflicts. It could be something to do with the fact that my base development is still on 2.4.18 (so the ancestors are easier to manage).
I finally solved it by writing a script to backport a bitkeeper change set to an earlier ancestor while preserving the change logs. This is going to be helpful taking change sets between 2.4 and 2.5 anyway.
Thanks,
James
Quoted 5 lines · James Bottomley
Quoted 2 lines · [email protected] said:
Through the magic of BK :)
Quoted 7 lines
Quoted 4 lines
Just do a 'bk pull' on my marcelo-2.4 tree. Since it is based on the original linux-2.4 tree just like Marcelo's tree, I was able to merge from my 2.4 line to his 2.4 line.
Well, I tried this, but it just gave me a slew of initial rename conflicts.
This is normal, you just need to accept the remote changes for all those new/renamed files. BitKeeper doesn't support doing this automatically for all files, so I had to highlight the expected BitKeeper response in another window, and then click <paste> on my mouse around 300 times... (~300 new files)
Jeff
Quoted 7 lines · David Woodhouse
Quoted 4 lines · [email protected] said:
BK works that way on purpose. If we merge changes into your local
changes, there is no automatic way to "unmerge". It is way to easy to do a pull, do the merge, and then realize you lost work in the merge because you told it to do the wrong thing.
Quoted 5 lines
Quoted 1 line
Short summary: commit your changes before you pull and you'll be fine.
If it was changes that deserved a changelog, I'd have committed them. But it's typically one-line hacks to make it compile, which I know will be obsoleted by 'correct' fixes in Linus' tree later.
Then you get to save them as diffs, unedit the files, and put them back after the merge.
Quoted 2 lines
Btw, the citool is cute but would be cuter if
- the diffs were '-up' format - showing the function that the hunk is in.
citool is a tcl program, how about you hack it in? Look for $diffsOpts, that's what you'll need to modify. You need to get the diffs parsing code to do the right thing with -up style diffs though.
Quoted 1 line
- You could select a hunk and say "omit this change from what's committed"
Get bk-2.1.5. We added multiple options to the edit button, try the fmtool option and learn how to use it. You can trivially walk the code and pick and choose which diffs you want.
Quoted 9 lines
Another thing I have a distinct feeling I'm going to want is tracking functions across files. I sometimes shuffle functions between files for portability - selective compilation is nicer with your Linux-specific functions in one file and eCos-specific functions in another than with a litter of ifdefs. If Linus' tree gets a patch to a file that I moved, BK can work it out. If Linus' tree gets a patch to a _function_ that I moved to a different file while leaving the rest of the original file in place, AFAICT not even the merge tool deals with that nicely. Did I miss an option to 'apply this diff hunk to a different file'?
We don't have this feature. We've talked about it, but that's all we've done.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 2 lines · [email protected] said:
Then you get to save them as diffs, unedit the files, and put them
back after the merge.
I can do better than that. If I save them as diffs, I don't get to use your cute merge tools. I could commit them with a throwaway changelog, do the pull and use the merge tools, then copy the resulting files, undo both the pull and the previous merge, do the pull again and then lock the files and drop the previously-saved copies into place.
It's a bit contrived though - it would be nice if BK would do something like that for me instead of just bailing out when files are modified. Asking me if I'm really sure I want to continue is fine. Aborting unconditionally less so.
Quoted 3 lines
citool is a tcl program, how about you hack it in? Look for
$diffsOpts, that's what you'll need to modify. You need to get the diffs parsing code to do the right thing with -up style diffs though.
Er, actually I can't get 'bk diffs -up' to give output the same as (GNU) 'diff -up' either. What I was after was stuff like:
@@ -331,6 +331,7 @@ int jffs2_decompress(unsigned char compr
Quoted 2 lines
We don't have this feature. We've talked about it, but that's all we've done.
Which? Actually tracking functions that move between files, or the hack in the merge tool? I appreciate that the former is a _lot_ harder to achieve.
--
dwmw2
Quoted 8 lines · Jeff Garzik
Quoted 2 lines
Well, I tried this, but it just gave me a slew of initial rename conflicts.
This is normal, you just need to accept the remote changes for all those new/renamed files. BitKeeper doesn't support doing this automatically for all files, so I had to highlight the expected BitKeeper response in another window, and then click <paste> on my mouse around 300 times... (~300 new files)
Yuck. So you knew without any doubt what it was that you wanted? How? If this is a common case, I can add an option to the resolver, but it strikes me that there must be some other problem here. What are those 300 files?
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 10 lines · David Woodhouse
Quoted 2 lines · [email protected] said:
Then you get to save them as diffs, unedit the files, and put them
back after the merge.I can do better than that. If I save them as diffs, I don't get to use your cute merge tools. I could commit them with a throwaway changelog, do the pull and use the merge tools, then copy the resulting files, undo both the pull and the previous merge, do the pull again and then lock the files and drop the previously-saved copies into place.
Well, what we're doing in PPC-land is we've got one tree, 'linuxppc-2.5' which is linux-2.5 + for-linus-ppc* trees + hacks/fixes for current problems. So when we do any work you make a clone of a linux-2.5 tree to work in, a clone of the linuxppc-2.5 tree (to pull your work tree into and then test). Once things are good in the linux-2.5-work tree, you pull that into a for-linus tree and tell linus to merge that.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 4 lines · Larry McVoy
Quoted 2 lines · Jeff Garzik
Quoted 2 lines
Well, I tried this, but it just gave me a slew of initial rename conflicts.
Quoted 8 lines
Quoted 2 lines
This is normal, you just need to accept the remote changes for all those new/renamed files. BitKeeper doesn't support doing this automatically for all files, so I had to highlight the expected BitKeeper response in another window, and then click <paste> on my mouse around 300 times... (~300 new files)
Yuck. So you knew without any doubt what it was that you wanted? How? If this is a common case, I can add an option to the resolver, but it strikes me that there must be some other problem here. What are those 300 files?
I started with Linus's linux-2.4 repo and so did Marcelo. We independently checked in 2.4.recent patches (including proper renametool use), which included the ia64 and mips merges, which added a ton of files. When you do a 'bk pull' from Marcelo's linux-2.4 into my old marcelo-2.4 repo, you have to individually tell BitKeeper that you really do want to trust Marcelo's copy over my own, for each of the ~300 new files that were added between Linus's linux-2.4 repo creation and 2 days ago. So I highlighted "rl\ny\n" in another window, and wore out my middle mouse button... Renames could have been handled similarly, but there were few renames, so I just typed "r\ny\n" manually maybe 10 or 20 times.
One could argue that a "rla" or "lla" command would be useful when resolving a conflict between two new files, telling BitKeeper to accept remote (or local) additions in this case _and_ all succeeding cases.
One could also argue that BitKeeper needs to be twacked on the head because it is not detecting that the file-creates and file-renames are 100% the same, content-wise.
Jeff
Quoted 4 lines · Jeff Garzik
I started with Linus's linux-2.4 repo and so did Marcelo. We independently checked in 2.4.recent patches (including proper renametool use), which included the ia64 and mips merges, which added a ton of files.
OK, so there is the root cause. It's time to talk about duplicate changes. You know how Linus hates bad csets in the history and doesn't want them there? Well, I hate duplicate csets and don't want them there. There are lots of reasons. One reason is that it means revtool is a lot less useful for debugging. If you are trying to track down the change which caused a bug but it is obscured by a duplicate patch, you just got hosed. Another reason is file creates. Suppose you and Marcelo both created a file called "foo". You pull, there is a file conflict, you remove one of the two files. It isn't actually removed, it's just moved to BitKeeper/deleted. Time passes and you or someone else is fixing bugs in a pre-merged copy of the tree and you are updating "foo". You later pull that bugfix into the merged tree and the bugfix happily is applied to the *deleted* copy of the file, since the changes follow the "inode", not the pathname. Bummer, you are now scratching your head wondering where your bugfix went.
There are things we can do in BK to deal with this, but they are not easy and are going to take several months, is my guess. I'd like to see if you can work around this by avoiding duplicate patches. If you can, do so, you will save yourself lots of grief.
If you get into a duplicate patch situation, you are far better off to pick one tree or the other tree as the official tree, and cherrypick the changes that the unofficial tree has and place them in the official tree. Then toss the unofficial tree. I can make you a "bk portpatch" command which does this, we have that already, it needs a bit of updating to catch the comments.
You really want to listen to this, I'm trying to head you off from screwing up the history. If you get 300 renames like this, it's almost always a duplicate patch scenario.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · [email protected] said:
If you get into a duplicate patch situation, you are far better off to
pick one tree or the other tree as the official tree, and cherrypick
the changes that the unofficial tree has and place them in the official tree. Then toss the unofficial tree. I can make you a "bk portpatch" command which does this, we have that already, it needs a bit of updating to catch the comments.
That's essentially what I had to write to move my trees over, so an official one would be extremely useful. I do have the piece which catches the comments if you want it.
Quoted 2 lines · [email protected] said:
So, knowing that duplicate patches are a bad thing helps not in the least here...
If bitkeeper had a way of replacing duplicate patches, this would be extremely useful. All I really needed to do was replace the keys in the changelog from the garzik tree with the mareclo one to get my changes moved over. I think essentially this could be done with a bk send|bk receive as long as I can tell bitkeeper that it needs a substitute set of keys when applying the bkpatch.
James
Quoted 7 lines · Larry McVoy
Quoted 2 lines · Jeff Garzik
I started with Linus's linux-2.4 repo and so did Marcelo. We independently checked in 2.4.recent patches (including proper renametool use), which included the ia64 and mips merges, which added a ton of files.
OK, so there is the root cause. It's time to talk about duplicate changes.
[...]
Quoted 4 lines
There are things we can do in BK to deal with this, but they are not easy
and are going to take several months, is my guess. I'd like to see if you
can work around this by avoiding duplicate patches. If you can, do so, you will save yourself lots of grief.
[...]
Quoted 3 lines
You really want to listen to this, I'm trying to head you off from screwing
up the history. If you get 300 renames like this, it's almost always a duplicate patch scenario.
I know why it happened, silly.
This was just an example of a real world example that actually happened, where BK sucked ass :)
Marcelo's BK tree did not exist when I created my marcelo-2.4 tree. marcelo-2.4 repo existed for a while and people started using it. Once Marcelo appeared with his "official" BK tree, people naturally want to migrate. There were two migration paths: (1) export everything to GNU patches, or (2) click the mouse 300 times.
So, knowing that duplicate patches are a bad thing helps not in the least here...
Jeff
Quoted 2 lines · Jeff Garzik
This was just an example of a real world example that actually happened, where BK sucked ass :)
Think file systems. Think 2 file systems. Think creating duplicate inodes in the same place. Now those 2 file systems are merged into a third, the duplicates removed. The original 2 still both exist and are both being updated.
Quoted 5 lines
Marcelo's BK tree did not exist when I created my marcelo-2.4 tree.
marcelo-2.4 repo existed for a while and people started using it. Once
Marcelo appeared with his "official" BK tree, people naturally want to migrate. There were two migration paths: (1) export everything to GNU patches, or (2) click the mouse 300 times.
There is a 3rd: factor out the duplicates and and export/import only the ones that Marcelo didn't have, then dump your tree and use his.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 10 lines · Larry McVoy
Quoted 2 lines · Jeff Garzik
This was just an example of a real world example that actually happened, where BK sucked ass :)
Think file systems. Think 2 file systems. Think creating duplicate inodes in the same place. Now those 2 file systems are merged into a third, the duplicates removed. The original 2 still both exist and are both being updated.
Like I said, I know why BK is going what it is doing. That doesn't change the fact that peoples options are very poor in this case.
Quoted 6 lines
Quoted 2 lines
Marcelo's BK tree did not exist when I created my marcelo-2.4 tree. marcelo-2.4 repo existed for a while and people started using it. Once Marcelo appeared with his "official" BK tree, people naturally want to migrate. There were two migration paths: (1) export everything to GNU patches, or (2) click the mouse 300 times.
There is a 3rd: factor out the duplicates and and export/import only the ones that Marcelo didn't have, then dump your tree and use his.
That's what I meant by option #1... you yelled at me, rightly, when I first tried to send BK patches to Linus, because I used 'bk export'. If you have to leave the BK system entirely for certain cases of merging, that's really a failing of the system. So, I chastise you back for even suggesting 'export' :)
Basically you need out of order changes to do it right...
I think a fair question would be, is this scenario going to occur often? I don't know. But I'll bet you -will- see it come up again in kernel development. Why? We are exercising the distributed nature of the BitKeeper system. The system currently punishes Joe in Alaska and Mikhail in Russia if they independently apply the same GNU patch, and then later on wind up attempting to converge trees.
Do you see what I'm getting at? In a widely distributed SCM system for an open source project, chances are -good- that some random two or more people will independently apply the same patch.
Jeff
Quoted 3 lines · [email protected] said:
The system currently punishes Joe in Alaska and Mikhail in Russia if
they independently apply the same GNU patch, and then later on wind up attempting to converge trees.
I tried to work round this by applying some patches which I require but which Linus hasn't yet taken _only_ in my working tree, not actually committing them.
But then BK wouldn't even let me pull from Linus' tree any more, because I had locked and modified files. That also seems to be a fundamental flaw.
--
dwmw2
Quoted 2 lines · David Woodhouse
But then BK wouldn't even let me pull from Linus' tree any more, because I had locked and modified files. That also seems to be a fundamental flaw.
BK works that way on purpose. If we merge changes into your local changes, there is no automatic way to "unmerge". It is way to easy to do a pull, do the merge, and then realize you lost work in the merge because you told it to do the wrong thing.
Short summary: commit your changes before you pull and you'll be fine.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · [email protected] said:
BK works that way on purpose. If we merge changes into your local
changes, there is no automatic way to "unmerge". It is way to easy to do a pull, do the merge, and then realize you lost work in the merge because you told it to do the wrong thing.Short summary: commit your changes before you pull and you'll be fine.
If it was changes that deserved a changelog, I'd have committed them. But it's typically one-line hacks to make it compile, which I know will be obsoleted by 'correct' fixes in Linus' tree later. I don't want them (and the subsequent merges and conflicting new files) cluttering up my tree, especially as AFAICT BK won't let me undo the change later if I commit any changes after it - even if the later changes are _completely_ unrelated.
Btw, the citool is cute but would be cuter if
- the diffs were '-up' format - showing the function that the hunk is in.
- You could select a hunk and say "omit this change from what's committed"
Again, the latter is because some stuff really does live as local hacks in a build tree and never deserves the honour of a changelog entry.
Another thing I have a distinct feeling I'm going to want is tracking functions across files. I sometimes shuffle functions between files for portability - selective compilation is nicer with your Linux-specific functions in one file and eCos-specific functions in another than with a litter of ifdefs. If Linus' tree gets a patch to a file that I moved, BK can work it out. If Linus' tree gets a patch to a _function_ that I moved to a different file while leaving the rest of the original file in place, AFAICT not even the merge tool deals with that nicely. Did I miss an option to 'apply this diff hunk to a different file'?
--
dwmw2
Quoted 6 lines
I think a fair question would be, is this scenario going to occur often?
I don't know. But I'll bet you -will- see it come up again in kernel
development. Why? We are exercising the distributed nature of the BitKeeper system. The system currently punishes Joe in Alaska and Mikhail in Russia if they independently apply the same GNU patch, and then later on wind up attempting to converge trees.
Indeed. So speak in file systems, because a BK package is basically a file system, with multiple distributed instances, all of which may be out of sync. The problems show up when the same patch is applied N times and then comes together. The inodes collide. Right now, you think that's the problem, and want BK to fix it. We can fix that. But that's not the real problem. The real problem is N sets of diffs being applied and then merged. The revision history ends up with the data inserted N times.
I'm not sure what to do about it. I can handle the duplicate inode case more gracefully but it's a heavy duty rewack.
We could play games where we detect the same patch inserted multiple times and refuse to merge them. Hmm. Hmm. Not sure that helps.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 10 lines · Larry McVoy
Quoted 2 lines
I think a fair question would be, is this scenario going to occur often? I don't know. But I'll bet you -will- see it come up again in kernel development. Why? We are exercising the distributed nature of the BitKeeper system. The system currently punishes Joe in Alaska and Mikhail in Russia if they independently apply the same GNU patch, and then later on wind up attempting to converge trees.
Indeed. So speak in file systems, because a BK package is basically a file
system, with multiple distributed instances, all of which may be out of
sync. The problems show up when the same patch is applied N times and then comes together. The inodes collide. Right now, you think that's the problem, and want BK to fix it. We can fix that. But that's not the real problem. The real problem is N sets of diffs being applied and then merged. The revision history ends up with the data inserted N
times.
Quoted 3 lines
I'm not sure what to do about it. I can handle the duplicate inode case more gracefully but it's a heavy duty rewack.
Hence my suggestion for a short term solution that's immediately useful -- allowing some way to answer "local changes take precedence 100% of the time" or "remote changes ..." with a single command. That was my hack solution that I thought would people might find useful when stuck with the duplicate-patch situation.
In the command line merge tool, when merging a file-create, "rla" would cause the current file conflict, and all future file-create conflicts, to be "won" by the remote side -- essentially creating the effect of typing "rl" 300 times. Apply similar logic to the file-rename merge case. I think the merge command I used in 100% of the cases, during that merge, was 'r'.
If you are stuck with the duplicate patch case, as happened here, I just want to see the pain eased a bit :) IMO you can put off the hard problem if you make the UI a bit better.
Jeff
Quoted 6 lines · Jeff Garzik
Hence my suggestion for a short term solution that's immediately useful -- allowing some way to answer "local changes take precedence 100% of the time" or "remote changes ..." with a single command. That was my hack solution that I thought would people might find useful when stuck with the duplicate-patch situation.
Quoted 6 lines
In the command line merge tool, when merging a file-create, "rla" would cause the current file conflict, and all future file-create conflicts, to be "won" by the remote side -- essentially creating the effect of typing "rl" 300 times.
Apply similar logic to the file-rename merge case. I think the merge command I used in 100% of the cases, during that merge, was 'r'.
One variant of this would be to automatically use the remote file as long as the file contents are the same. That way, if I apply a patch locally and Marcello/Linus later apply the same patch and put it into the official tree, I can use the official version. This would probably handle most of the conflicts I have seen so far. If there are any "real" conflicts, I can handle them manually.
/Christer
Signature · 1 line
"Just how much can I get away with and still go to heaven?"
Quoted 10 lines · Larry McVoy
Quoted 2 lines
I think a fair question would be, is this scenario going to occur often? I don't know. But I'll bet you -will- see it come up again in kernel development. Why? We are exercising the distributed nature of the BitKeeper system. The system currently punishes Joe in Alaska and Mikhail in Russia if they independently apply the same GNU patch, and then later on wind up attempting to converge trees.
Indeed. So speak in file systems, because a BK package is basically a file
system, with multiple distributed instances, all of which may be out of
sync. The problems show up when the same patch is applied N times and then comes together. The inodes collide. Right now, you think that's the problem, and want BK to fix it. We can fix that. But that's not the real problem. The real problem is N sets of diffs being applied and then merged. The revision history ends up with the data inserted N
times.
Another thought, that I'm betting you laugh at me for even suggesting :)
Don't insert the data N times. Give the user the option to say that one or more changesets are actually the same one. In filesystem speak, unlink a file B which is a user-confirmed duplicate of file A, and re-create file B as a symlink to file A. Or just unlink file B without the symlink, whichever metaphor suits you better. :)
Yes it is "altering history"... but... OTOH the user has just told BitKeeper, in no uncertain terms, that he is altering history only to make it more correct.
From a user interface perspective, the user would pick one of N changeset comments to be considered the "real" one.
Jeff
Quoted 28 lines · Jeff Garzik
Quoted 8 lines · Larry McVoy
Quoted 7 lines
I think a fair question would be, is this scenario going to occur often? I don't know. But I'll bet you -will- see it come up again in kernel development. Why? We are exercising the distributed nature of the BitKeeper system. The system currently punishes Joe in Alaska and Mikhail in Russia if they independently apply the same GNU patch, and then later on wind up attempting to converge trees.
Quoted 9 lines
Indeed. So speak in file systems, because a BK package is basically a file system, with multiple distributed instances, all of which may be out of sync. The problems show up when the same patch is applied N times and then comes together. The inodes collide. Right now, you think that's the problem, and want BK to fix it. We can fix that. But that's not the real problem. The real problem is N sets of diffs being applied and then merged. The revision history ends up with the data inserted N times.
Another thought, that I'm betting you laugh at me for even suggesting :)
Don't insert the data N times. Give the user the option to say that one or more changesets are actually the same one. In filesystem speak, unlink a file B which is a user-confirmed duplicate of file A, and re-create file B as a symlink to file A. Or just unlink file B without the symlink, whichever metaphor suits you better. :)
Quoted 3 lines
Yes it is "altering history"... but... OTOH the user has just told BitKeeper, in no uncertain terms, that he is altering history only to make it more correct.
You need to put on the distributed-think hat. The problem is never what I do in any one instance, we can do all sorts of useful things in that instance. The problem is doing them in such a way so that synchronization with repositories which are both ahead and behind works. So if you repull from whereever you just pulled from, the system needs to remember that some cset is a duplicate and has been eliminated. And if you pull in the opposite direction, the past events, including duplicate removal, propagate.
*All* of this stuff is trivial if you don't care about passing it on, if your repository is a backwater dead end. But that's not the case. So you have to decide that you want the events to propagate and if you do, then we can do something about it.
I'm starting to get psyched about this, I think I see a picture that works, I need to chew on it for a bit though.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 8 lines · Larry McVoy
Quoted 2 lines
Yes it is "altering history"... but... OTOH the user has just told BitKeeper, in no uncertain terms, that he is altering history only to make it more correct.
*All* of this stuff is trivial if you don't care about passing it on, if your repository is a backwater dead end. But that's not the case. So you have to decide that you want the events to propagate and if you do, then we can do something about it.
Re-read my message, assuming I have a clue :) This fits just fine into the distribute BK system, across any number of pushes and pulls.
I -would- want to pass on the fact that I merged multiple changesets into a single one...
Think about this example:
* I merge a GNU patch into tree A, creating cset 1.111.
* Marcelo merges the same GNU patch into tree B, creating cset 1.222.
* Time passes. People clone repos off of both trees.
* I 'bk pull' from tree B. Through the merge process, this creates a brand new "symlink cset", 1.333, which propagates the notion that my cset 1.111 is a complete copy of 1.222, so we should just read the data and revision history from 1.222.
* Now, I 'bk push' some changes to Marcelo. This pushes, among other things, the magic symlink cset 1.333. It does not push 1.111, since 1.333 was the change to the local repo that told it not to. Think of this like "cset -x" except smarter. "cset -x", as I understand it, creates a new cset which is essentially the reverse of the specified cset. Our symlink cset says to BitKeeper (a) not bother with patch-and-unpatch if both 1.111 and 1.222 are found to be missing downstream, and (b) if 1.111 but 1.222 are present downstream, to remove the data associated with 1.111, turning it into a symlink to 1.222.
This fits perfectly well into the BK distributed system, and works across any number of bk pushes and pulls. Basically, "symlink csets" would show up in 'bk changes', much like merge csets show up in 'bk changes' now.
And you are no longer inserting the data N times. The symlink csets take care of that.
And further, for people scattered all over the world with 1.111 cset, the 1.333 cset will slowly worm its way across the world, acting like a janitor and cleaning up BK repositories with duplicated patches :) Isn't that neat? :) (assuming that 1.333 cset is propagated out to the world, of course)
Quoted 2 lines
I'm starting to get psyched about this, I think I see a picture that works, I need to chew on it for a bit though.
whichever works :)
Jeff, who really should sleep now :)