[Scons-dev] Mercurial and the current SCons workflow are incompatible?

[Martin Geisler]

Russel Winder <russel at winder.org.uk> writes:

Hi guys,

I don't have the full overview yet of what has happened, but you seem to
be in some sort of distress... and maybe confusion: Git and Mercurial
work the same with regard to published changes and with regard to
rewriting history.


> On Sun, 2012-10-14 at 16:10 +0200, Thomas Berg wrote:

> […]

>

>> have run into this too. When a branch is merged prematurely, and

>> rewriting history isn't an option, the solution is to "revert" the

>> merge on the main branch, and then "revert the revert" on the branch

>> where you want the changes back for further development. Sounds

>> complicated, but It simply means you resubmit the changes that were

>> reverted, on a suitable branch. Usually this is easy, unless there

>> have been conflicting commits in the mean time.

>

> The problem in this case is that reverting the revert appears not

> sensible for a repository that is supposed to then generate pull

> requests to the mainline :-((


As I said, I haven't followed the development of Scons closely, so I
don't know exactly what this "D branch" is (I'm guessing some support
for the D language?).

In any case: if you publish a repository and intend to generate pull
requests from such a repository, then you should not merge anything into
this repository. In Mercurial, I normally work on my branch locally and
continiously rebase it to stay current with the official repo.

When the work is done and ready for review, then I publish the
changesets on some public repo and ask someone to pull them into the
main repo -- maybe with an email, maybe with a pull request on
Bitbucket. That's not really the important point.

If there are review comments that I need to take into account, then I
would either

a) delete the scratch repo and fix the history locally to take the
   comments into account. I then push the new and improved history to a
   new scratch repository and create another pull request.

b) create additional changesets to fix whatever needs to be fixed and
   push those to the repo with the branch under review. This creates a
   more authentic history and requires less work, but the result might
   be slightly more inconvenient to understand when someone looks back
   at the changes in a year or two.

If option a) becomes the norm, then people might find it easier overall
to submit changes for review using patches. That way they can rewrite
the local history all they want and they just need to send a new patch
bomb when done -- no fiddling around with deleting remote branches
(using the strip interface in Bitbucket) or repos.


> And using a branch branch for feature development is not a good idea

> with Mercurial. :-(((


Using named branches or not doesn't change anything here as far as I can
tell. Neither does bookmarks.


> I think the question here is whether this situation merits some form

> of rewriting history on a published repository.

>

> Clearly it is simpler and easier to annoy SCons_T_Tooling users than

> SCons users, and I can see a way of achieving the needful by exporting

> the diffs rather than the changesets and reapplying them to a new fork

> of the mainline. The problem is though that there may still be

> conflicts trying to reapply the resultant changesets to the mainline

> due to the backout commit.


Remember that we have 'hg graft' -- that command copies changesets and
lets you resolve any conflicts with the full three-way merge machinery.

In general, I don't think you need to rewrite public history. If you
have some "bad" commits, then you can mark the head as closed and
continue from somewhere good.

I don't know if it's actually relevant here, but let me mention it just
in case: Remember that Mercurial and Git are only concerned with the
final states when merging: if you merge heads X and Y, then *all* that
matters are the content of the files in X, Y, and their common ancestor
Z. So if you can get the content of X, Y, and Z to be "good", then it
doesn't matter at all how many backouts and weird commits you have
between Z and X and between Z and Y.

(It's a common misconception that DVCS makes merging easier because the
many small commits people make give more information to the system and
that they're somehow "replayed" at merge time. That's not how merges
work in Mercurial.)


> Overall, I think the simplest thing to do here is to rewrite SCons

> history to remove the D commit and backout and make sure everyone with

> write authority retools themselves to avoid recommitting the D-related

> bits. OK this will annoy anyone with a SCons fork, but I think it may

> be better to do that than leave the problem in the repository.


-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/scons-dev/attachments/20121015/8929dfdb/attachment.pgp>