Re: Branched development with hg flow

[Marty K. <mrk...@co...>]

On 08/29/2013 09:42 AM, Ralph Lange wrote:
> On 29.08.2013 14:58, Marty Kraimer wrote:
>> On 08/28/2013 08:51 AM, Ralph Lange wrote:
>>> Here you go:
>>>
>>> http://epics-pvdata.sourceforge.net/hgflow/using_hgflow.html
>>>
>>> Please read ... understand ... digest ... try out the shell script 
>>> ... complain.
>>
>>
>> For "hg flow init" you suggest:
>> Branch name for master stream: [default] master
>> Branch name for develop stream: [develop] default
>> This matches with how we are currently operating, i. e. we develop on 
>> the main branch which mercurial calls default.
>
> Exactly. We have legacy commits on the 'default' branch, which match 
> conceptually the 'develop' trunk.
>
>> What is new for us is that all releases will be generated from branch 
>> master.
>>
>> This is different than what readers who understand the "Driessen 
>> branching model" may expect, i. e. that master is default and develop 
>> is develop
>> So just state it up front in the Introduction.
>> Then the external document makes sense.
>
> Ok, will do.
>
>> Should the branch named master be created now in all modules that are 
>> part of release 3.0?
>> I think Yes.
>>
>>
>> How do we get existing projects ready for hg flow while also getting 
>> ready for release 3.0.
>
> Hold your horses.
> Greg has explicitly asked for nothing to happen before he nods his 
> head in favour.
>
> Let's please wait until 3.0 is completely out and done before starting 
> to change repository structures.

OK. It is getting confusing about what will be done for release 3.0 and 
what we do after it is ready.
Having procedures like You are suggesting will be a big help for future 
releases!!!

>
> (And I did actually expect some discussion about this model being too 
> complicated and not suited well enough. I don't want to let my 
> prepared argumentation lines go to waste...)
>
>> Something like:
>>
>> In existing development tree
>> initialize hg flow as per Ralph's instructions
>> hg flow develop
>> update documentation/*.html files.
>> add documentation/RELEASE_NOTES.html
>> hg commit
>
> Yes.
>
>> hg flow master
>> hg merge default
>> hg commit
>> hg push
>> hg flow develop
>
> No, it would be along the lines of:
>
> hg flow release start 3.0
> (fix everything for the release)
> hg flow release finish
>
> That workflow should be part of the example repo created by the script.
>
>> Note that pvDataCPP will be a special  case,
>> I think itt will require a branch named 3.0.
>>
>> I am thinking of how I will organize my hg tree.
>>
>> Maybe something like:
>>
>> hg/
>>    hgflow.py        // now all .hg/hgrc can have flow = 
>> /home/hg/hgflow.py
>
> Wherever you want to put the python file.
> BUT: "flow = /path/to/hgflow.py" is set only once, in the .hgrc in 
> your home directory.

Makes complete sense.

The install and Configuration instructions do say what goes in the.hgrc 
in the home directory and what goes in the hg configuration file.
BUT the way it is presented is easy to misread. I suggest it be changed to

<h3>Download hgflow</h3>
... first two list items
<h3>Modify .hgrc</h3>
<p>Edit ~/.hgrc (or %USERPROFILE%/Mercurial.ini on Windows).</p>
   ... list items 2-4
<h3>Modify hgrc</h3>
<p>In each module edit the .hg/hgrc file</p>
... last list item


>
>> The reason to have two for each module is configuration files like 
>> RELEASE.local.
>> If commands like "hg flow master" is issued while on branch develop 
>> then the RELEASE.local will be wrong.
>
> The RELEASE.local files are not under version control.
> Keep just one of each module, and put one single RELEASE.local file 
> one directory level above all the modules.

This is NOT an argument against what I am thinking.
We are managing multiple mercurial repositories.
Just consider two: pvDataCPP and pvAccessCPP.

If I have the directory structure:

hg/
    Release.master   // RELEASE.local that has references to XXXmaster
    Release.develop // RELEASE.local that has a reference to XXXdevelop
    pvDataCPPmaster
        configuration
             RELEASE.local -> ../../ Release.master
   pvDataCPPdevelop
         configuration
             RELEASE.local -> ../../ Release.develop
   pvAccessCPPmaster
       configuration
             RELEASE.local -> ../../ Release.master
   pvAccessCPPdevelop
       configuration
             RELEASE.local -> ../../ Release.develop

Then everything is compatible.
Note that pvAccessCPPmaster may not build against pvAccessCPPdevelop

If  your development structure is

hg/
    RELEASE.local
    pvDataCPP
    pvAccessCPP

Then when you change branches via "hg flow develop" and "hg flow 
master"  in pvAccessCPP then you must also do it in pvDataCPP AND 
rebuild in each repository,
And do it in the correct order , i. e. first in pvDataCPP and then in 
pvAccessCPP.

Marty


>
> Cheers,
> ~Ralph
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk