[Rivet] HG transition

[Andy Buckley]

Please do! (The answer to this sort of question is always "yes" ;-) )

Thanks,
Andy


On 10/06/13 18:09, Frank Siegert wrote:
> Thanks, David!
> 
> These clarifications are very useful since I have so far not used a
> distributed version control system. Do you want me to add these to
> GettingStartedForDevelopers (together with a link to hginit.com)?
> 
> Cheers,
> Frank
> 
> 
> On 10 June 2013 00:03, David Grellscheid <david.grellscheid at durham.ac.uk> wrote:
>> Hi Frank,
>>
>>>> New features should _not_ get added there, instead development happens
>>>
>>>
>>> I'm confused now. I thought if I want to add a new analysis I would
>>> simply clone that "trunk", implement my changes locally (potentially
>>> with intermediate local commits) and when I'm finished pull and merge
>>> any updates and then push my stuff back.
>>
>>
>> Correct. With "features" I meant structural changes to the core of Rivet.
>> New analyses that are completely standalone are OK direct to trunk with the
>> workflow you describe. If you need to coordinate with another author, you
>> could push to a temporary branch in 'private' first.
>>
>>> Maybe just for clarification if I misunderstood the workflow, or as a
>>> basis for the wiki page:
>>>
>>> (0. Clone the repo -- just once at the beginning)
>>> $ hg clone ssh://login.hepforge.org//hepforge/hg/rivet/public/rivet
>>> $ cd rivet
>>
>>
>> Yes. The path is automatically encoded in rivet/.hg/hgrc as "default =
>> ssh://login.hepforge.org//hepforge/hg/rivet/public/rivet",
>> so that pull/push operations do not need an explicit destination.
>>
>>>
>>> 1. Implement one new feature
>>> $ hg pull
>>> $ hg update
>>> $   # develop first part of change
>>> $ hg commit -m "first part of my change"
>>> $   # develop second part of change
>>> $ hg commit -m "second part of my change"
>>
>>
>> Yes.
>>
>>>
>>> 2. Get updates from central repo
>>> $ hg pull
>>> $ hg merge
>>> $ hg commit -m "merge"
>>>
>>
>> Yes.
>>
>>> 3. Push to central repo
>>> $ hg push
>>
>>
>> Correct. Push/pull can come from any repo path. You can either explicitly
>> specify the target, or use shortcuts that you can add by hand to .hg/hgrc.
>> This is useful when you're on a branch and want to track trunk as the branch
>> develops. hgrc would then have
>>
>> [paths]
>> default = ..../branchrepo
>> trunk = ..../trunkrepo
>>
>> Then you can regularly do
>>
>> 4. Track trunk in branch repo
>> hg pull trunk
>> hg merge
>> hg ci -m'merge'
>> hg push  # implies "default"
>>
>> This keeps 'branch' up-to-date with developments on trunk.
>>
>>>> on individual branches in
>>>>
>>>> hg clone ssh://login.hepforge.org//hepforge/hg/yoda/private/...
>>>> hg clone ssh://login.hepforge.org//hepforge/hg/rivet/private/...
>>>
>>>
>>> How does one create such a private branch (or is it called
>>> repository)?
>>
>> They're all separate repositories. Even your hg clone makes a new repo, and
>> they are all equal. commit/update talks to the repo underneath your working
>> dir, while pull/push coordinates with other repo clones.
>>
>> The most space-efficient way to create private clones on hepforge is to ssh
>> into login.hepforge.org, then do the following (clone on the local
>> filesystem uses hardlinking as long as files are unchanged):
>>
>> 5. Create new branch repo in hepforge
>> umask 002
>> cd /hepforge/hg/rivet/
>> hg clone public/rivet private/foobar
>>
>> In principle, one can also clone via ssh to a new location in private, but
>> then without the space savings.
>>
>>> And how are they merged back into the mainline?
>>
>> Just as above, but you push to trunk instead of default:
>>
>> 6. Merge branch repo back to trunk
>> cd privaterepo-workdir
>> hg pull trunk
>> hg merge
>> hg ci -m'merged'
>> hg out trunk # check what will be pushed, maybe use -r to select
>> hg push trunk # be SURE of this, it's hard to undo, -r applies here, too
>>         ^^^^^
>>
>> Once you understand the difference between (2.), (4.) and (6.), you've got
>> it! You can create a couple of local clones on your own machine and
>> experiment with all the different features. I also found http://hginit.com/
>> very useful.
>>
>> See you,
>>
>>   David
> 


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Edinburgh / PH Dept, CERN