[Rivet] HG transition

[Frank Siegert]

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