[Scons-dev] Workflow

Dirk Bächle tshortik at gmx.de
Thu Jun 14 15:58:10 EDT 2012


Hi Rob,

for my last bugfix (and pull request) I used Mercurial's bookmark
feature successfully. I guess with your current commits the problem is
that both changesets have the (implicit) branch "default", so Bitbucket
can't decide what you want to do: 1) update your old pull request with
additional changes, or 2) create a new pull request.

What I'll do for further development is:

- leaving the default branch alone (this is where upstream changes
from the official SCons repo come in),
and mark it with

hg bookmark origin

- for each new bug, I add a new bookmark, like

hg bookmark bug2180

By updating to a bookmark (hg update bug2180, for example) it gets
active, and a commit then progresses the "bug2180" pointer to the new
changeset. Note, how you can switch to a different bug, or the default
branch with

hg update xyz

anytime.
When finally pushing your local changes up to Bitbucket, you can then
create a pull request by selecting one of your bookmarks as origin.
Good thing about this is, that once the changes are merged in, your
local bookmarks aren't visible in the mainline...so, no branches to close.

Hope this helps you a little further.

Best regards,

Dirk

On 14.06.2012 19:47, Managan, Rob wrote:

> Gary,

>

> Sorry to pester you but for clarity I wanted to split my recent work into

> two pull requests. The first I have already created the pull request for.

> It adds support for a new latex package, biblatex. The second part is to

> allow the user to use biber instead of biblatex with env['BIBTEX'] =

> 'biber'; which requires the builder to know about side effects with

> different extensions....

>

> I pushed a commit with the second set of changes up to the same fork. If I

> click on create pull request it says it will modify the first one. I

> supposeI should wait and let you accept the first one and then create a

> new pull request? Or should I not worry about keeping the two related bits

> in separate updates to the main default branch??

>

> Any ideas?

>

> Rob

>

>

>

>

> On 6/14/12 9:28 AM, "Gary Oberbrunner"<garyo at oberbrunner.com> wrote:

>

>> On Thu, Jun 14, 2012 at 11:34 AM, Managan, Rob<managan1 at llnl.gov> wrote:

>>> I need a refresher on what the best workflow is for small changes.

>>>

>>> In the emails from Martin Geisler around May 8 2012 it sounded like we

>>> were

>>> going away from named branches for small simple additions.

>>>

>>> I am not seeing any changes yet

>>> on http://scons.org/wiki/SconsMercurialWorkflows and was not quite sure

>>> what

>>> the procedure is.

>> I did update it a few weeks ago:

>>

>> "Then to work on a bug or feature the simplest thing is to work

>> directly on the default branch. Feature branches are not usually

>> needed except for long-term development, but you're welcome to work

>> that way if you like. You can just make your changes (including doc

>> and tests); when you're happy, commit them, and push:"

>>

> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

> Rob Managan email managan at llnl.gov

> LLNL phone: 925-423-0903

> P.O. Box 808, L-095 FAX: 925-422-3389

> Livermore, CA 94551-0808

>

>

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

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

>




More information about the Scons-dev mailing list