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

[William Deegan]

Martin,
On Oct 14, 2012, at 10:40 PM, Martin Geisler <martin at geisler.net> wrote:


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


Could you list the commands to do this. (none of use are super knowledgable on mercurial (yet:))?



> 

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


Our pull request volume is usually ~1-3/week.
If we do the strip, then we would need to ask all forks to do the same if they'd already merged?

Thanks!
-Bill Deegan
Co-Manager SCons Project.