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

[Martin Geisler]

Gary Oberbrunner  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


pgpk6OxG6mH3w.pgp
Description: PGP signature
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [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
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Martin Geisler]

Russel Winder  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


pgpgGJqc2qIJM.pgp
Description: PGP signature
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Martin Geisler]

Russel Winder  writes:

> Gary,
>
> This seemingly just gets worse.
>
> From: http://mercurial.selenic.com/wiki/Backout
>
> Warning
> 
> Backing out a merge will lead to trouble if you ever want to
> redo the merge. The only safe way to deal with a bad merge is to
> abandon the branch.
>
> I think the corollary of this for the SCons workflow is "we're screwed".

I believe I added that warning :) And the example on the wiki page
should show that this behavior is a consequence of how three-way merges
work -- as far as I remember.

As a side remark: It would be good if someone could write the Mercurial
mailinglist (mercur...@selenic.com) with a summary of what's wrong and
how to proceed -- there's a lot of clever people there, including Matt
Mackall who designed Mercurial.


Reverting a published merge is hard (I believe it's hard in Git too).
That is one reason why premature merging is really bad: you *commit*
yourself to the result in a strong way.

One way to "fix" a merge in Mercurial is to abandon it: redo the merge
(correctly this time) and abandon the bad merge:

  $ hg update "p1(bad-merge)"
  $ hg merge "p2(bad-merge)"
  $ hg commit -m "Better version of bad-merge"
  $ hg update bad-merge
  $ hg commit --close-branch -m "Use  instead"

That will leave you with a dangling topological head, but that is fine
with modern Mercurial. People who have local work based on bad-merge
will simply rebase it to new-merge and push.

-- 
Martin Geisler


pgp4dHNssgbTN.pgp
Description: PGP signature
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [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  wrote:

> 
> 
> On Sun, Oct 14, 2012 at 12:17 PM, Russel Winder  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@scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

[Scons-dev] SCons logo images

[William Deegan]

Dirk,

Re: images..

It might make sense to just make a new repo for "marketing" collateral?
Including the images (both rendered and .svg)?

What do you think?
I'm not sure putting it on the web repo is the right place (since it's private 
at the moment, and we probably want to keep that for just the release team).

Thoughts?
-Bill

On Oct 14, 2012, at 2:46 PM, Dirk Bächle  wrote:

> Hi Gary,
> 
> and a very big "Thanks!" to you in return, for taking the lead over this 
> bunch of crazy SCons guys, which are all doing very good work (Hey Russel, 
> the new SCons intro page looks awesome!).
> It's a real pleasure to drive this interesting and challenging project 
> further, together with all you nice people
> out there... :)
> 
> Regards,
> 
> Dirk
> 
> P.S.: Soon to come are the final fixes for the still failing WinXP 
> Buildslave, and after that the new docs toolchain. So fasten your seat-belts 
> everyone... ;)
> 
> On 13.10.2012 17:06, Gary Oberbrunner wrote:
>> I just wanted to give a bit shout-out to Dirk Baechle, who has worked 
>> heroically over the last few weeks to get the SCons buildbots green again 
>> (buildbot.scons.org).  He not only revamped the test system to allow test 
>> fixtures (both files and directories) and make it possible to run tests 
>> outside the SCons source tree, but also made a lot of test cleanups to get 
>> both Linux and Windows passing all the tests.
>> 
>> In other news, check out the new look on our bitbucket site, 
>> https://bitbucket.org/scons/scons; Russel Winder just converted the 
>> top-level README to much nicer looking RST format so it's much more readable.
>> 
>> -- 
>> Gary
>> 
>> 
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> http://two.pairlist.net/mailman/listinfo/scons-dev
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Thanks!

[Dirk Bächle]

Hi Gary,

and a very big "Thanks!" to you in return, for taking the lead over this 
bunch of crazy SCons guys, which are all doing very good work (Hey 
Russel, the new SCons intro page looks awesome!).
It's a real pleasure to drive this interesting and challenging project 
further, together with all you nice people

out there... :)

Regards,

Dirk

P.S.: Soon to come are the final fixes for the still failing WinXP 
Buildslave, and after that the new docs toolchain. So fasten your 
seat-belts everyone... ;)


On 13.10.2012 17:06, Gary Oberbrunner wrote:
I just wanted to give a bit shout-out to Dirk Baechle, who has worked 
heroically over the last few weeks to get the SCons buildbots green 
again (buildbot.scons.org ).  He not only 
revamped the test system to allow test fixtures (both files and 
directories) and make it possible to run tests outside the SCons 
source tree, but also made a lot of test cleanups to get both Linux 
and Windows passing all the tests.


In other news, check out the new look on our bitbucket site, 
https://bitbucket.org/scons/scons; Russel Winder just converted the 
top-level README to much nicer looking RST format so it's much more 
readable.


--
Gary


___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev


___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Gary Oberbrunner]

On Sun, Oct 14, 2012 at 12:17 PM, Russel Winder 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@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Russel Winder]

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

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.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

[Scons-dev] Mercurial repositories

[Russel Winder]

Gary,

As a totally disruptive backstop position:  I run a generational backup
system so I have yesterdays and the day before's repositories of SCons
and have captured copies of the backups. If the worst comes to the worst
we could revert the mainline to a pre D tools merge version and remake
Rob's changes.

This will annoy people with clones who have updated but if we make
publicity big and loud, they may forgive us.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Thomas Berg]

Hi,

On Sun, Oct 14, 2012 at 12:32 PM, Russel Winder  wrote:
> To backout, Mercurial doesn't remove a changeset (which is what Git
> does), it adds a new changeset undoing the commit. This means that I can
> no longer merge the mainline tip into the D_Tooling fork to ensure a
> good pull request in the future, since that will just delete all the D
> tooling support.
>
> I am assuming then I have to take a new fork of mainline and reimpose
> the change sets over the backout to create D tooling fork – which as a
> workflow completely sucks. Not to mention adding more and more replica
> commits to the repository. Given what is possible with Git, this
> situation with Mercurial really sucks.

The equivalent thing is just as problematic in git: if you "revert a
merge" (using "git revert"), and make the change public, the same
thing happens: you have not "undone" the merge, but instead created a
new changeset that undoes everything that was delivered in the merge.

The only difference with git is that it is easier to rewrite the
history to delete the entire merge commit from history, using 'git
reset' or 'git rebase' for example (which you normally wouldn't do
when the history is public).

At my dayjob we use Perforce, and since this is a fundamental problem
(independent of SCM, as long as the merge algorithm is similar) we
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.

- Thomas
(scons and git user)
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Gary Oberbrunner]

On Sun, Oct 14, 2012 at 9:36 AM, Russel Winder  wrote:

> On Sun, 2012-10-14 at 09:28 -0400, Gary Oberbrunner wrote:
> […]
> >
> > I posted a question on Stack Overflow.
> >
> http://stackoverflow.com/questions/12882672/how-can-i-back-out-a-backout-of-a-merge-in-mercurial--
>  hopefully someone will have good advice.
>
> I think a point that comes out of this is that we need a CI system which
> clones mainline merges a pull request and then runs the tests. Doing CI
> on mainline is really just marketing.
>

:-)  Bill, as the buildbot guy, what do you think of this?  I'm not sure
how we'd make this work.  It would be really cool though if we had auto
testing of each pull request!  If it's hard to do this, is there something
simpler (maybe only semi-automatic)?

Apologies for causing this chaos. On the other hand I'd rather have the
> chaos and fix the underlying problem so we don't have it again!
>
> Agreed.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Gary Oberbrunner]

http://stackoverflow.com/questions/4152480/how-can-i-back-out-a-merge-in-mercurial-and-later-remerge-with-that-branch

seems to say, in "Merge pushed, you don't have control over clones", that
we could somehow continue to work on the commits prior to the merge and
leave the old head (with the merge and backout) dangling.  Does this seem
plausible?
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Russel Winder]

On Sun, 2012-10-14 at 09:28 -0400, Gary Oberbrunner wrote:
[…]
> 
> I posted a question on Stack Overflow.
>  
> http://stackoverflow.com/questions/12882672/how-can-i-back-out-a-backout-of-a-merge-in-mercurial
>  -- hopefully someone will have good advice.

I think a point that comes out of this is that we need a CI system which
clones mainline merges a pull request and then runs the tests. Doing CI
on mainline is really just marketing.

Apologies for causing this chaos. On the other hand I'd rather have the
chaos and fix the underlying problem so we don't have it again!

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Gary Oberbrunner]

On Sun, Oct 14, 2012 at 8:50 AM, Russel Winder  wrote:

> Gary,
>
> This seemingly just gets worse.
>
> From: http://mercurial.selenic.com/wiki/Backout
>
> Warning
>
> Backing out a merge will lead to trouble if you ever want to
> redo the merge. The only safe way to deal with a bad merge is to
> abandon the branch.
>
> I think the corollary of this for the SCons workflow is "we're screwed".


I posted a question on Stack Overflow.
http://stackoverflow.com/questions/12882672/how-can-i-back-out-a-backout-of-a-merge-in-mercurial--
hopefully someone will have good advice.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Russel Winder]

Gary,

This seemingly just gets worse.

From: http://mercurial.selenic.com/wiki/Backout

Warning

Backing out a merge will lead to trouble if you ever want to
redo the merge. The only safe way to deal with a bad merge is to
abandon the branch.

I think the corollary of this for the SCons workflow is "we're screwed".
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

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

[Russel Winder]

Gary,

I understand you backing out of the commit of the D stuff due to Windows
problems. However because of the way Mercurial seems to do things, this
appears to have completely broken the D tool development capability. If
we had been using Git there would not have been a problem(*).

To backout, Mercurial doesn't remove a changeset (which is what Git
does), it adds a new changeset undoing the commit. This means that I can
no longer merge the mainline tip into the D_Tooling fork to ensure a
good pull request in the future, since that will just delete all the D
tooling support.

I am assuming then I have to take a new fork of mainline and reimpose
the change sets over the backout to create D tooling fork – which as a
workflow completely sucks. Not to mention adding more and more replica
commits to the repository. Given what is possible with Git, this
situation with Mercurial really sucks.

Unless, of course, someone understands Mercurial better than I and knows
how to fix this and create a sane workflow.

Or perhaps we have to ask Martin Geisler to give us some more advice?

How do the Python folks cope with this sort of thing?


(*) Every day I use Mercurial and Git in anger, the more I don't like
Mercurial and the more I prefer Git – even though Git sucks, it sucks in
ways I can cope with.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev