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

[Gary Oberbrunner]

OK.  Martin and everyone, thanks for your thoughts on this!  I think we
have three possible courses of action.

1a: Russel, in his repo, reapplies his changes (somehow) to the current
tip, and we move forward from there.
1b: Russel, in his repo, backs out my backout, applies some fixes, and
resubmits a pull request.

Downside: repo history is ugly, and Russel's changes possibly end up in one
big commit, and his job is harder.  Upside: not sure.

2: I or Bill (as maintainer) use
https://bitbucket.org/scons/scons/admin/strip to reset the  bitbucket repo
back to just before the bad merge.  I think this would make the new tip:
   f461304: Merged pull request #44 (make README a ReStructuredText file)
(Rob M would have to resubmit pull request #46.)

Downside: anyone who's got local changes based on tip will be confused, and
there's a risk of the stripped changesets coming back on push.  But this is
all very recent and probably everyone who cares is reading this, and only a
few people have push privileges to bitbucket/scons/scons.  Upside: nice
clean repo history, and Russel can just resubmit his pull request with his
fixes.

3: We take Martin's advice, and abandon the merge changeset.  I'm not
actually sure how to do this in a bitbucket context.  Martin, assuming we
just want to go back to f461304 (see
https://bitbucket.org/scons/scons/changesets), and move forward from there,
abandoning everything since then (all Russel's changes, which were on
default in his repo as well as merging Rob Managan's change 3771fa3), what
do we do?  I'm not sure how Bitbucket will handle multiple heads -- will
one be the visible "main" one?

Downside: I don't know how to do this, and it's all done on our public
bitbucket, so it's a bit dangerous.  (Martin: your version dealt with named
branches; we're all on default.)  Upside: agrees with Martin's advice as
well as a Stack Overflow question I saw.

Opinions?  I think I like #2 best, as it seems simple enough and will get
us back to a good state quickly.  I'd go with #3 if people say it's better
in some way and I get good instructions.

-- Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20121014/35dc9cfe/attachment.html>