Re: VCS comparison table

On 17 Oct 2006, Shawn Pearce [off-list ref] wrote:

Aaron Bentley [off-list ref] wrote:

quoted

Jakub Narebski wrote:

quoted

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.

But this only works when the URL is public.  In Git I can just lookup
the unique SHA1 for a revision in my private repository and toss it
into an email with a quick copy and paste.  

Yes, but then people need to know how to get it out of your private
repository.  For stuff that goes into well-known repositories I suppose
it just propagates.

With Bazaar it sounds like I'd have to do that relative to some known
public repository, which just sounds like more work to me.

You can also name a revision using its UUID, in which case things will
work similarly to git.  We tend to often say "in r1234 of dev".

But I don't want to see this otherwise interesting thread devolve into
a "we do X better!" match so I'm not going to say anything further here.

Sure.

quoted

quoted

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'.

Git has two approaches:

 - merge: The two independent lines of development are merged
   together under a new single graph node.  This is a merge commit
   and has two parent pointers, one for each independent line of
   development which was combined into one.  Up to 16 independent
   lines can be merged at once, though 12 is the record.

 - rebase: The commits from one line of development are replayed
   onto a totally different line of development.  This is often
   used to reapply your changes onto the upstream branch after the
   upstream has changed but before you send your changes upstream.
   It can often generate more readable commit history.

I believe what you are talking about in Bazaar is the former (merge)
while what Jakub was talking about was the latter (rebase).

For the 'rebase' operation in Bazaar you can use 'bzr graft':

  http://spacepants.org/src/bzrgraft/

-- 
Martin