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