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

[Martin Geisler]

Gary Oberbrunner <garyo at oberbrunner.com> writes:


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


This option 3 should be the safest: you mark the head (8764000) as
closed locally and push to Bitbucket. You can then make a new commit
From somewhere good (f461304) and that will be it. I've done that here:

  https://bitbucket.org/mg/scons/changesets

The closed head is hidden from 'hg heads' by default and if a branch has
nothing but closed heads, then the branch itself is hidden from 'hg
branches'. That's all there is to this --close-branch mechanism.


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


Rewriting public history all depends on how many people you expect to
annoy... if you get 10 pull requests per week and those people would
need to recreate some work if you strip the Bitbucket repo, well then
you might want to avoid it. If you get 1 pull request per week and if
most contributors read this list, well then go ahead.

-- 
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/93c72010/attachment-0001.pgp>