VCS comparison table

Jakub Narebski jnareb at gmail.com
Wed Oct 18 00:35:24 BST 2006


Dnia wtorek 17. października 2006 23:01, Jakub Narebski napisał:
> Aaron Bentley wrote:
> > Andreas Ericsson wrote:
> >> Aaron Bentley wrote:
> >>> Ah.  Bazaar uses negative numbers to refer to <n>th parents, and
> >>> positive numbers to refer to the number of commits that have been made
> >>> since the branch was initialized.
> >>>
> >>
> >> What do you do once a branch has been thrown away, or has had 20 other
> >> branches merged into it? Does the offset-number change for the revision
> >> then, or do you track branch-points explicitly?
> > 
> > We always track the number of parents since the initial commit in the
> > project.  Sorry, I don't think I said that clearly before.
> 
> While this I think is quite reliable (there was idea to store "generation
> number" with each commit, e.g. using not implemented "note" header, or
> commit-id to generation number "database" as a better heuristic than
> timestamp for revision ordering in git-rev-list output), and probably
> independent on repository (it is global property of commit history,
> and commit history is included in sha1 of its parents), numbering branching
> points is unreliable, as is relying on branch names.

Take for example the following situation:


In the following we had

  A--B--C--D  - repository A

we have cloned repository

  A--B--C--D  - repository B

Then, in parallel/independently we branched off C in repository A, and
branched off B in repository B

          -x
         /
  A--B--C--D  - repository A


  A--B--C--D  - repository B
      \
       -y

If we then fetch changes from B into A, and fetch changes from A into B,
we will have that in repository A branch off C appeared earlier, and
in repository B branch off C appeared later.
-- 
Jakub Narebski
Poland




More information about the bazaar mailing list