|
From: Marty K. <mrk...@co...> - 2013-08-30 13:10:40
|
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 |