One of the things I like in git is its lightweight branching. I can branch now and continue the work.
What BK has to offer for this kind of scenario?
2 Likes
Yes, git allows lightweight branches by allowing a single repository to contain multiple open tips of the revision history graph. It also allows quickly switching between those tips in place.
In bk, a single repository can only have a single tip and so to track multiple tips you need multiple repositories. This is less flexible than git’s approach but not any less powerful. Which is to say there isn’t a workflow that git allows that can’t be done in bk.
The biggest difference is if your project takes a long time to build and you have not included any derived object caching in your build solution, then switching tips in-place might save time rebuilding.
So if you are working on the new release and a bugfix comes in for the last release the workflow would look something like this.
git
(apologies if I get some git syntax wrong, I am not an expert. 
)
$ git stash
$ git checkout -b bk-7.2.1.fixbug bk-7.2.1
... develop and fix bug ...
$ git add -A
$ git commit
$ git push <somewhere>
$ git checkout master
$ git stash pop
... continue working ...
bk
$ bk clone -rbk-7.2.1 . ../bk-7.2.1.fixbug
$ cd ../bk-7.2.1.fixbug
... develop and fix bug ...
$ bk citool
$ bk push bk://machine/bk-7.1.x
$ cd ../original-repo
... continue working ...
Of course, a git user can use multiple repos the same way as bk, but the difference isn’t really that big.
That said we have been working on supporting multiple tips in bk, but that code is not yet ready for public consumption.
I know that BK supported LODs at some point. Just wondering what happened to it? Was it considered causing too much trouble in practice?
And yet another historical note. Other VCSes unofficially called their branching as LODs too, but abandoned that name due to copyright concerns.
So, it seems that BK was actually the first VCS to support branches, but diverged from that approach later.
The BitKeeper LOD support was added and removed from bk before I started in 2001, so they are old history.
@vvs your reply feels very odd to me because of the terminology. I started using VC tools with RCS and then was an expert in CVS before joining BitKeeper. So the word “branches” equates to the types of things you would create a branch for in a centralized repository. So BitKeeper supports branching in a much more flexible manner than any of the systems before. Every repository is a branch and potentially a fork in development. And unlike previous systems, you didn’t need to plan ahead to start a branch/fork, every change is a branch and only when it is eventually pushed back to the mainline it was integrated.
Now I understand that git has used the term ‘branch’ to name tips in the current repository, so I just need to adjust my brain because that idea is what you are actually talking about.
That especially sounds odd. Lots of VCS had “branches” before bk. It sounds like you mean bk was the first DVCS to support multiple tips in the same repository. Perhaps, but I am not sure I would count the old LOD stuff.
Right, I meant that it was the first distributed system to support that. The whole concept was very influential at the time, even the terminology. I read some threads about it on the Internet quite some time ago. Sorry, for not making it clear.
BTW, I do not mean to discount the original question.
Anyone have an example of a workflow where git’s branches allow a significate advantage over what bk allows currently? Or one where I can attempt to give the BitKeeper equivalent of the same operation. With limited development resources, it would be good to spell out what is to be gained by adding multi-tip support to bk.
I don’t think there is a significant advantage. It’s just a convenience. But if you switch branches frequently and especially create a short lived ones, it’s a significant convenience. That all depends on a particular workflow preference. I gave an example of such a workflow in another thread about lightweight bug fixing.
Just in case: I was not challenging anything, I just wanted to find a way that “mimics” what git offers.
On a somewhat related theme, a few colleagues of mine are very happy about ‘git worktree’, which seems to be in line with what bk offers for branching.
BTW, vim and emacs have plugins which allow you to visually track the current branch in which you are working, e.g. powerline. It’s very convenient.
Another thought. Bisecting is only effective if you can fix the bug at the point of introduction. Imagine that you have a tree ridden with bugs that doesn’t even compile or run most of the time. Fixing it at the tip is of no use if you need to find out what happened at the earlier points. The most effective way I can think of is branching at the bisect point, fixing the bug and rebasing on top of it. Then you can at least continue to search for another bug. I was able to fix dozen of bugs a day in a totally unfamiliar code.
Yes, bisect is a good example of where quickly switching between csets in place is very useful. BitKeeper does have a bisect command and it works by making a clone of the repository and then adding or removing csets until the problem cset is found. Not as fast as git’s version, but it works and usually all the time is spent building and testing each version anyway.
We also considered building bisect as exporting a source tree that was not a repository and then just updating the files according to what changed between revisions. This would be just as fast as git, but we probably didn’t go this way because bk itself wouldn’t build outside of a repository.
Note this only works for unpublished commits. Otherwise you’re stuck with the history you have.
Other than that, yeah… agreed.
Of course. But you can always merge these fixes into published branch later.
I am not sure about the significant advantage. My workflow is
$ git checkout -b feature master $ ... hack hack hack ... $ git fetch origin $ git rebase origin/master
and later either “merge and push” or “rebase and push”…
When working with an IDE like Eclipse, ‘… develop and fix bug …’ requires creating and configuring a new (temporary) project, which can be quite cumbersome.
With git’s ‘in place branches’ you can continue to work with your current project in Eclipse (and even create/switch branches directly from within the IDE).
The biggest difference is if your project takes a long time to build and you have not included any derived object caching in your build solution, then switching tips in-place might save time rebuilding.
Actually, you give git too much credit for fast rebuilding. When you switch branches (tips) in git, git sets the date of all working tree files to “NOW.” So, you are forced to do a rebuild, which is smart. Therefore, git also depends on derived object caching for speed, just like bitkeeper’s multiple repositories.