4 ms·

Git would do well to copy BitKeeper's nested repository architecture. Unlike Git, a collection of nested repositories (what we call submodules) works exactly l

Git would do well to copy BitKeeper's nested repository architecture. Unlike Git, a collection of nested repositories (what we call submodules) works exactly like a monolithic repository. Want to see diffs for your tree? Same command. Want to check in your changes? Same command. Want to update your collection? Same command. Etc. It's a lot more work than the hack that is submodules (we understand that hack, we did exactly the same thing for years to track outside source drops). But it is worth it, everything just works. http://www.mcvoy.com/lm/bkdocs/nested.html http://www.mcvoy.com/lm/bkdocs/nested.html http://www.mcvoy.com/lm/bkdocs/productline.pdf http://www.mcvoy.com/lm/bkdocs/productline.pdf

krupan 10y ago
I'm really intrigued by this. I love mercurial (and tolerate git), but they both handle sub repositories poorly. How much of my mercurial (and/or git) muscle memory would I have to unlearn to switch to bk. Just for basic commands, I mean. You could tell me to go try it out myself, but a nice side-by-side comparison showing that bk does all that git/hg do (if that's true) could go a long way to attracting git/mercurial people over to bk.
- luckydude 10y ago
  Well we support fast-import so you can get your history into BK and play trivially. BK does more and less than git/hg. It's got richer history, it was trivial to write a bk fast-export that git could import. Writing a bk fast-import wasn't so bad but an incremental one is hard because git doesn't store as much history (no per file history, actually no file object, just pathnames that have some data, not the same, we have a DAG per file, makes history better, makes merges faster and easier). Mercurial copied our UI so for a lot of stuff if you know hg <cmd> then bk <cmd> will just work. BK predates all these systems, they picked up some of bk's commands. There is a cheatsheet (somewhat out of date but it will get you going) at: http://mcvoy.com/lm/bkdocs/bk_refcard.pdf http://mcvoy.com/lm/bkdocs/bk_refcard.pdf And you can email dev <at> bitkeeper.com or hit up http://bitkeeper.org http://bitkeeper.org for more info. Cheers.

krupan 10y ago

I'm really intrigued by this. I love mercurial (and tolerate git), but they both handle sub repositories poorly. How much of my mercurial (and/or git) muscle memory would I have to unlearn to switch to bk. Just for basic commands, I mean. You could tell me to go try it out myself, but a nice side-by-side comparison showing that bk does all that git/hg do (if that's true) could go a long way to attracting git/mercurial people over to bk.

luckydude 10y ago
Well we support fast-import so you can get your history into BK and play trivially. BK does more and less than git/hg. It's got richer history, it was trivial to write a bk fast-export that git could import. Writing a bk fast-import wasn't so bad but an incremental one is hard because git doesn't store as much history (no per file history, actually no file object, just pathnames that have some data, not the same, we have a DAG per file, makes history better, makes merges faster and easier). Mercurial copied our UI so for a lot of stuff if you know hg <cmd> then bk <cmd> will just work. BK predates all these systems, they picked up some of bk's commands. There is a cheatsheet (somewhat out of date but it will get you going) at: http://mcvoy.com/lm/bkdocs/bk_refcard.pdf http://mcvoy.com/lm/bkdocs/bk_refcard.pdf And you can email dev <at> bitkeeper.com or hit up http://bitkeeper.org http://bitkeeper.org for more info. Cheers.