Re: VCS comparison table

From: Martin Pool <mbp@sourcefrog.net>
Date: Oct 17, 2006, 08:21 UTC
Message-ID: <20061017082159.GB5215@sourcefrog.net>
In-Reply-To: <20061017052019.GB21210@spearce.org>

On 17 Oct 2006, Shawn Pearce <spearce@spearce.org> wrote:

Show 14 quoted lines

> Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> > Jakub Narebski wrote:
> > > 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.

Show 26 quoted lines

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