On Sun, Oct 29, 2006 at 01:01:07PM +0100, Jakub Narebski wrote: > > You can give Bazaar for me, a bk user, and I can understand what to do > > with the branches that are like bk clones. (The repository stuff is > > later development and still optional.) Switching a CVS environment to > > Bazaar one can be done so that most of the users can be just told to > > use bzr checkout and they don't have to care about pushing. > > That is of course because you are familiar with branch-centric distributed > SCM, namely BitKeeper, when trying Bazaar-NG. IMHO branch-centric view > is somewhat limiting; you can always use repository-centric SCM with > one-live-branch-per-repository paradigm and emulate branch-centric SCM, > which is not (or not always) the case for branch-centric SCM. Branch-centric > and repo-centric SCM promote different workflows, namely parallel uncommited > work on few development branches for branch-centric SCM, one-change > per-commit multiple temporary and feature branches for repo-centric SCM. I've got to disagree here. Being a former bitkeeper user myself, I find BZR-NG to be nothing like bk. In particular, Bitkeeper is *not* branch-centric the way that BZR is; in fact, bk is much closer to git and bk both in terms of how it works and its terminology. You can have a non-linear set of history without using any "branches" in both bk and mercurial, simply by creating two commits changing different files in two different repositories (using the bk, git, and hg sense of the word --- only bzr attaches a completely different definitoin to term "repository"), and then pull them together. With bzr, the only way you can do the following is by explicitly creating a separate branch and then merging the two branches together. In bzr --- unlike bk, git, and hg --- when you are on a "branch" the history must be completely linear. The difference between bk, and git and hg, is that bk enforces a restriction that there must be one "head", or "tip" on a particular repository (in the bk, hg, and git sense). So if you start by cloning the repository A -> B, and then make one or more commits in repository A, and then one or more commits in repository B, when you pull from repository B to A, bk will enforce the creation of a merge changeset on the resulting repository --- or fail the merge. (Actually, with BK there was the option to create multiple tips using "lines of development", but it was never fully developed or supported.) With hg and git, you have the *option* of pulling the two lines of commits together using a merge changeset *or* leaving the two "tips" or "heads" unmerged. But that's only a very minor difference between bk and hg/git --- and if you are willing to always merge two heads after pulling so that your git or hg repository only has one head/tip, then conceptually the changeset history is just like bk. In contrast, it's impossible to do this with bzr without leaving the named branches around, so in this sense it's quite different form BK. - Ted P.S. I'm going to teaching a class entitled "Bzr, Hg, and Git, Oh my!" at LISA conference in Washington, D.C. It's only a half-day tutorial intending to cover the basics of Distributed SCM systems, so most folks on this list will probably know everything I'm planning on discussing, but if you have some colleagues who need a gentle introduction, please feel tell them to head on over to the LISA conference website at www.usenix.org. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html