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

[William Deegan]

Russel,

Would you use git rebase in this situation?

I like the idea about pull requests being run in buildbot, I'll investigate. There is a REST API on bitbucket to get the pull requests.
We'd want to be careful though about automatically running any and all pull requests because someone could do something malicious in their submitted changes which would be bad to just automatically run.
However with some manual intervention (Approve to run pull request on buildbot) it might make sense.

-Bill

On Oct 14, 2012, at 12:24 PM, Gary Oberbrunner <garyo at oberbrunner.com> wrote:


> 

> 

> On Sun, Oct 14, 2012 at 12:17 PM, Russel Winder <russel at winder.org.uk> wrote:

> 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 :-(( And using a branch branch for feature

> development is not a good idea with Mercurial. :-(((

> 

> Couldn't you just package up all your changes and reapply (all at once or individually) on the current tip?

>  

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

> 

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

>  

> If we need to do this, here is how:

> 

>  http://stackoverflow.com/questions/9627964/how-can-i-completely-replace-a-bitbucket-repository-with-another-repository 

> 

> -- 

> Gary

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev


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