[Scons-dev] Fwd: [Bitbucket] Pull request #119: Major revamp of the D language support (scons/scons)
This is worth reading, IMHO. From Martin Geisler. You can see more in the pull request (which has been withdrawn, so you won't see it by browsing open PRs on bitbucket), where he explains why pulling Russel's change causes an explosion of branchiness due to mercurial's changeset ordering. -- Forwarded message -- From: Martin Geisler pullrequests-re...@bitbucket.org Date: Wed, Mar 19, 2014 at 7:11 AM Subject: Re: [Bitbucket] Pull request #119: Major revamp of the D language support (scons/scons) To: ga...@oberbrunner.com Martin Geisler commented on pull request #119: Major revamp of the D language support [image: mg] *Martin Geisler* commented on pull request #119: Major revamp of the D language supporthttps://bitbucket.org/scons/scons/pull-request/119/major-revamp-of-the-d-language-support#comment-1456338 One thing that I should have mentioned is that a Mercurial to Mercurial conversion that only reorders revisions ought to produce the same changeset hashes. This conversion is really only doing something you could do by hand if you ran $ hg init empty$ cd empty$ hg pull -r X https://bitbucket.org/scons/scons$ hg pull -r Y https://bitbucket.org/scons/scons$ hg pull -r Z https://bitbucket.org/scons/scons with suitably choses revisions X, Y, Z (try with X being 712d021dcacbhttps://bitbucket.org/scons/scons/commits/712d021dcacband Y being 66db0d6c3e3f https://bitbucket.org/scons/scons/commits/66db0d6c3e3f). As you know, revision numbers are local-only since they depend on the order of pulls and pushes. More precisely, revision numbers are local-only since they define the topological ordering used in your repository. By pulling in changes in an order we decide, we can also decide the topological ordering and pick one we think is prettier or one that common tools will draw in a prettier way. If the merges are tedious to you, then the alternative is to use rebase as you go along. If you also want to publish the changes, then you can do so in the form of a bundle that you distribute to people who need to test the code. Make sure they know how to strip the changes they pull from the bundle: when you rebase again you will publish a new bundle with the rebased changes. Your testers will then have to strip the previously unbundled changes and pull from the new bundle. Many projects ask contributors to submit changes as patches using the patchbomb extension. Testers then apply the patches with hg import. As review comments are integrated, the patches change. Since the commits haven't been published in a permanent form, the contributor can rebase them as needed locally. He'll then submit new patches when there's something interesting to show. This change in the future when changeset evolutionhttp://mercurial.selenic.com/wiki/ChangesetEvolutionbecomes more widely used (and Bitbucket eventually supports it). With that, you can rebase your commits and push the rebased version to a server. The new versions will mark the old versions as obsolete and the server will hide the old ones from clients. So this allows you to both eat your cake and have it to! By that I mean that you can push commit and then later change your mind (e.g., rebase them). People who have pulled the old versions of the commits will see them being hidden after they pull the new versions. If people have based work on the old versions the evolve extension can normally deduce how to rebase them onto the newer versions. This is still considered experimental, though, but I just wanted to mention that people are working on making this even better :-) View this pull requesthttps://bitbucket.org/scons/scons/pull-request/119/major-revamp-of-the-d-language-support#comment-1456338or add a comment by replying to this email. In reply to *Gary Oberbrunner* Hi Martin Geisler https://bitbucket.org/mg ; it looks like that could be our problem. Thanks for your analysis! Although in poor Russel's case there's a lot more merges than that, so the rev graph actually goes off my page even on a wide monitor! I don't think a graph like that would make us look very good. From a quick glance at the convert extension, it doesn't seem that it can do what we want; we'd have to replace the SCons repo with a new one. So what's the recommended practice here? Should Russel have been rebasing instead of merging all along? Of course he can just diff all his changes and apply the diff as one big patch, but that sort of defeats the purpose of a DVCS a bit. Unwatch this pull requesthttps://bitbucket.org/scons/scons/pull-request/119/unwatch/garyo/2655f05f3a8823a5c33a144e2c2f7178c8a60652/to stop receiving email updates.[image: Bitbucket] https://bitbucket.org -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Question about .../SCons/Platform/win32.py
At the beginning of .../SCons/Platform/win32.py there are approx. 40 lines that
try to overide the builtin functions 'file' and 'open'. Those are replaced with
versions that make sure, that files created/opened with those functions have
underlying os file handles that are not inheritable.
The reasoning for this seems to be that inheritable file handles might interfere
with parallel builds (-j). I can not say anything about that.
But i am very sure that on windows file handles are created as non inheritable
by default. And i am sure that the msvcrt functions that python (CPython) uses
do not touch that default handling.
It is easy to check whether the file handle for a python file is inheritable
or not. Just use the same method that .../SCons/Platform/win32.py is using:
import msvcrt
import win32api
f = open('inherit.txt', 'wt')
win32api.GetHandleInformation(msvcrt.get_osfhandle(f.fileno()))
0
As you can see, the flag HANDLE_FLAG_INHERIT is not set, ie. the handle is not
inheritable.
So my questions are:
Why is that code there?
Does it handle situations (different OS or python interpreter) that i didn't
think of?
Regards,
Rocco
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Big pull requests
On Tue, Mar 18, 2014 at 6:32 PM, Russel Winder rus...@winder.org.uk wrote: Gary tried hard to merge PR#119 over the weekend, but did not due to the insanity of the resulting changeset path structure. It is clear that Mercurial/BitBucket cannot handle pull requests from long-lived and frequently merged feature branch clones. Unless someone knows something Gary and I do not – which is quite likely as we both mostly use Git and are only used to simple Mercurial scenarios. This leads to two possibilities: 1. I create a single changeset from all the history of changes and submit a new pull request. 3. Transform into MQ and try to apply them on top on current head (basically an incremental rebase). ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Fwd: [Bitbucket] Pull request #119: Major revamp of the D language support (scons/scons)
Hi there, On 19.03.2014 15:08, Gary Oberbrunner wrote: This is worth reading, IMHO. From Martin Geisler. You can see more in the pull request (which has been withdrawn, so you won't see it by browsing open PRs on bitbucket), where he explains why pulling Russel's change causes an explosion of branchiness due to mercurial's changeset ordering. I took the time to read through the comments for this pull request, and now would like to share my first impression with you all. The merge graph may look a bit unusual, but this is simply the first time that a long-lived dev branch gets back onto default. I, personally, wouldn't feel the itch to do anything about it. Let graphs get messy and ugly, but this is what happens when you actually work with a VCS. Polishing, folding and rebasing commits only to make the history look pretty is not really required from my side...but let me stress this again, it's just my personal opinion. I really acknowledge and appreciate all the work that Russel, Gary and Martin have put into this. If you like a clean history better, fine...just continue. Especially if this removes your obvious doubts about whether Mercurial did the right thing (This merge looks mixed up, it can't be right.). But you don't have to do it for me. ;) Best regards, Dirk P.S.: Just as an addendum, trying to provide an explanation for what I wrote above...I see worse things every day, we're using ClearCase at work. ;) ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Fwd: [Bitbucket] Pull request #119: Major revamp of the D language support (scons/scons)
On Thu, Mar 20, 2014 at 1:09 AM, Dirk Bächle tshor...@gmx.de wrote: Let graphs get messy and ugly, but this is what happens when you actually work with a VCS. Polishing, folding and rebasing commits only to make the history look pretty is not really required from my side...but let me stress this again, it's just my personal opinion. I really acknowledge and appreciate all the work that Russel, Gary and Martin have put into this. If you like a clean history better, fine...just continue. Especially if this removes your obvious doubts about whether Mercurial did the right thing (This merge looks mixed up, it can't be right.). But you don't have to do it for me. ;) Best regards, Dirk P.S.: Just as an addendum, trying to provide an explanation for what I wrote above...I see worse things every day, we're using ClearCase at work. ;) Depends on the project. You probably use VCS just for storage. I use it also for troubleshooting, so the general rule - if you can't understand the flow of changes during review - what is the chance that you will understand it when everything goes down all of a sudden? If I have to revert a commit later, I need to be sure that there are no parts that are already critical for the other parts of the system. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
