[Rivet] HG transition

[Frank Siegert]

Argh, sorry -- I think I've done something stupid.

I committed some small changes locally, then did a pull/merge/commit,
and then pushed in the assumption that my small changes are then being
pushed. But if I look at the diff:

  hg diff -c08fb5598e16e

then there is a lot more stuff in it than expected, probably from the merge?

What did I do wrong here? I hope there's a way to fix it...

Cheers,
Frank


On 11 June 2013 12:01, Frank Siegert <frank.siegert at cern.ch> wrote:
> Ok, this is on https://rivet.hepforge.org/trac/wiki/GettingStartedForDevelopers
> now, feel free to amend/improve.
> Thanks again to David for the explanations!
>
> Frank
>
>
> On 10 June 2013 18:09, Frank Siegert <frank.siegert at cern.ch> 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