Re: VCS comparison table
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Oct 25, 2006, 09:46 UTC
- Message-ID
- <200610251146.06116.jnareb@gmail.com>
- In-Reply-To
- <453F2FF8.2080903@op5.se>
Andreas Ericsson wrote:
Show 18 quoted lines
> Matthew D. Fuller wrote: >> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of >> Carl Worth, and lo! it spake thus: >> >>> (since pull seems the only way to synch up without infinite new >>> merge commits being added back and forth). >> >> The infinite-merge-commits case doesn't happen in bzr-land because we >> generally don't merge other branches except when the branch owner says >> "Hey, I've got something for you to merge". If you were to setup a >> script to merge two branches back and forth until they were 'equal', >> yes, it'd churn away until you filled up your disk with the N bytes of >> metadata every new revision uses up. > > This is new to me. At work, we merge our toy repositories back and forth > between devs only. There is no central repo at all. Does this mean that > each merge would add one extra commit per time the one I'm merging with > has merged with me?
From what I understand, "bzr merge" will create one extra commit to preserve the "first parent is my branch" feature. "bzr pull" will do fast-forward if your DAG is proper subset of pulled branch/repository DAG, but at the cost that it would change your revno to revision mapping to those of the pulled repository.
That's a consequence of preserving branch as "my work" i.e. as path through "branch DAG" in the DAG using first parent as special, instead of saving it outside DAG.
-- Jakub Narebski