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