[Scons-dev] Fwd: [Bitbucket] Pull request #119: Major revamp of the D language support (scons/scons)

[Gary Oberbrunner]

This is worth reading, IMHO.  From Martin Geisler.  You can see more in the
pull request (which has been withdrawn, so you won't see it by browsing
open PRs on bitbucket), where he explains why pulling Russel's change
causes an explosion of branchiness due to mercurial's changeset ordering.

---------- Forwarded message ----------
From: Martin Geisler <pullrequests-reply at bitbucket.org>
Date: Wed, Mar 19, 2014 at 7:11 AM
Subject: Re: [Bitbucket] Pull request #119: Major revamp of the D language
support (scons/scons)
To: garyo at oberbrunner.com


       Martin Geisler commented on pull request #119: Major revamp of the D
language support
 [image: mg]  *Martin Geisler* commented on pull request #119:  Major
revamp of the D language
support<https://bitbucket.org/scons/scons/pull-request/119/major-revamp-of-the-d-language-support#comment-1456338>

One thing that I should have mentioned is that a Mercurial to Mercurial
conversion that only reorders revisions ought to produce the same changeset
hashes. This "conversion" is really only doing something you could do by
hand if you ran

$ hg init empty$ cd empty$ hg pull -r X
https://bitbucket.org/scons/scons$ hg pull -r Y
https://bitbucket.org/scons/scons$ hg pull -r Z
https://bitbucket.org/scons/scons

with suitably choses revisions X, Y, Z (try with X being
712d021dcacb<https://bitbucket.org/scons/scons/commits/712d021dcacb>and
Y being
66db0d6c3e3f <https://bitbucket.org/scons/scons/commits/66db0d6c3e3f>). As
you know, revision numbers are local-only since they depend on the order of
pulls and pushes. More precisely, revision numbers are local-only since
they define the topological ordering used in your repository. By pulling in
changes in an order we decide, we can also decide the topological ordering
and pick one we think is "prettier" or one that common tools will draw in a
prettier way.

If the merges are tedious to you, then the alternative is to use rebase as
you go along. If you also want to publish the changes, then you can do so
in the form of a bundle that you distribute to people who need to test the
code. Make sure they know how to strip the changes they pull from the
bundle: when you rebase again you will publish a new bundle with the
rebased changes. Your testers will then have to strip the previously
unbundled changes and pull from the new bundle.

Many projects ask contributors to submit changes as patches using the
patchbomb extension. Testers then apply the patches with hg import. As
review comments are integrated, the patches change. Since the commits
haven't been published in a permanent form, the contributor can rebase them
as needed locally. He'll then submit new patches when there's something
interesting to show.

This change in the future when changeset
evolution<http://mercurial.selenic.com/wiki/ChangesetEvolution>becomes
more widely used (and Bitbucket eventually supports it). With that,
you can rebase your commits and push the rebased version to a server. The
new versions will mark the old versions as obsolete and the server will
hide the old ones from clients. So this allows you to both eat your cake
and have it to! By that I mean that you can push commit and then later
change your mind (e.g., rebase them). People who have pulled the old
versions of the commits will see them being hidden after they pull the new
versions. If people have based work on the old versions the evolve
extension can normally deduce how to rebase them onto the newer versions.

This is still considered experimental, though, but I just wanted to mention
that people are working on making this even better :-)
  View this pull
request<https://bitbucket.org/scons/scons/pull-request/119/major-revamp-of-the-d-language-support#comment-1456338>or
add a comment by replying to this email.
  In reply to *Gary Oberbrunner*

Hi Martin Geisler <https://bitbucket.org/mg> ; it looks like that could be
our problem. Thanks for your analysis! Although in poor Russel's case
there's a lot more merges than that, so the rev graph actually goes off my
page even on a wide monitor! I don't think a graph like that would make us
look very good.


>From a quick glance at the convert extension, it doesn't seem that it can

do what we want; we'd have to replace the SCons repo with a new one.

So what's the recommended practice here? Should Russel have been rebasing
instead of merging all along? Of course he can just diff all his changes
and apply the diff as one big patch, but that sort of defeats the purpose
of a DVCS a bit.
       Unwatch this pull
request<https://bitbucket.org/scons/scons/pull-request/119/unwatch/garyo/2655f05f3a8823a5c33a144e2c2f7178c8a60652/>to
stop receiving email updates.    [image:
Bitbucket] <https://bitbucket.org>



-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140319/66177c5d/attachment-0001.html>