-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Narebski wrote:
quoted text
> Well, <ref>~<n> means <n>-th _parent_ of a given ref, which for branches
> (which constantly change) is a moving target.

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.

quoted text
> One cannot have universally valid revision numbers (even
> only per branch) in distributed development. Subversion can do that only
> because it is centralized SCM. Global numbering and distributed nature
> doesn't mix... hence contents based sha1 as commit identifiers.

Sure.  Our UI approach is that unique identifiers can usefully be
abstracted away with a combination of URL + number, in the vast majority
of cases.

quoted text
> But this doesn't matter much, because you can have really lightweight
> tags in git (especially now with packed refs support). So you can have
> the namespace you want.

The nice thing about revision numbers is that they're implicit-- no one
needs to take any action to update them, and so you can always use them.

quoted text
> I wonder if any SCM other than git has easy way to "rebase" a branch,
> i.e. cut branch at branching point, and transplant it to the tip
> of other branch. For example you work on 'xx/topic' topic branch,
> and want to have changes in those branch but applied to current work,
> not to the version some time ago when you have started working on
> said feature.

If I understand correctly, in Bazaar, you'd just merge the current work
into 'xx/topic'.

quoted text
> What your comparison matrick lacks for example is if given SCM
> saves information about branching point and merges, so you can
> get where two branches diverged, and when one branch was merged into
> another.

I'm not sure what you mean about divergence.  For example, Bazaar
records the complete ancestry of each branch, and determining the point
of divergence is as simple as finding the last common ancestor.  But are
you considering only the initial divergence?  Or if the branches merge
and then diverge again, would you consider that the point of divergence?

merge-point tracking is a prerequisite for Smart Merge, which does
appear on our matrix.

quoted text
> Plugins = API + detection ifrastructure + loading on demand.
> Git has API, has a kind of detection ifrastructure (for commands and
> merge strategies only), doesn't have loading on demand. You can
> easily provide new commands (thanks to git wrapper) and new merge
> strategies.

I'm not sure what you mean by API, unless you mean the commandline.  If
that's what you mean, surely all unix commands are extensible in that
regard.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNGKQ0F+nu1YWqI0RAsW+AJoDOsNRmBjo3raT43JL6qn7SuJNRwCfe9l5
oAZ9OyrxMQlHnwrruhcjz9Y=
=RNuG
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html