[Rivet] HG transition

[James Monk]

Hi Frank, David,

I'm also not quite getting my head around this now.  I already have a private repo for the jet tagging features that I'm adding.  Now I want to look at adding gzipped HepMC file support.  That's a completely independent feature, so should not be part of the jet tagging branch.

It seems to me that I shouldn't have to clone the trunk again from scratch, but should be able to add a branch to the repo I already have.  I want that to be a branch off the trunk though, not off my private jet tagging branch.  Does this mean I have to do something like

	hg pull
	hg commit # commit any local changes to the jet tagging branch
	hg update trunk #switch to the trunk branch locally
	hg branch gzip #make new branch for gzip
	hg commit #start committing to that new branch
... write code
	hg commit #final commit of gzip
	hg push
	hg update default #switch back to the jet tagging branch

Do I have that right?  It's almost making sense to me now :/

cheers,

James


On 1 Jul 2013, at 00:39, Frank Siegert wrote:

> Coming back to another issue: branches and private repos
> 
> As far as I can see, there are two different things which we have
> called branches earlier on in this thread:
> - Private repos are just that, i.e. they are cloned repos just like
> the one I have locally, except that they are stored on a central
> server such that they can be pulled from and pushed to easily from
> multiple devs.
> - Branches seem to be a named revision in a repo. I can switch to a
> different branch by using e.g.
> hg update -r 2012-06-aidarivet
> (check that this worked by doing hg parents)
> I can then simply do normal development commits and push them, and
> they'll end up in the correct branch.
> 
> By the way: I find it confusing, that our code browser at
> https://rivet.hepforge.org/trac/browser/
> will *dynamically* display the branch which had the last commit (i.e.
> right now 2012-06-aidarivet) instead of the default branch. Can that
> be changed to always show the default branch?
> 
> Now I noticed that our bootstrap script does not work in
> --dev-mode-aida, since it's trying to do:
>  $ hg pull -u 2012-06-aidarivet
>  abort: repository 2012-06-aidarivet not found!
> Is this supposed to be
>  $ hg pull -u -r 2012-06-aidarivet
> or is there a more elegant way?
> 
> Cheers,
> Frank
> 
> 
> On 25 June 2013 23:05, David Grellscheid <david.grellscheid at durham.ac.uk> wrote:
>> Hi Frank,
>> 
>> 
>>>>> So we should definitely include rebase in the workflow
>>>>> description for simple "direct" commits to trunk, right?
>>>> 
>>>> 
>>>> I'd prefer not to for now, it's only useful for really simple local
>>>> commit trees that commute easily with what was just pulled in. It's
>>>> complicated enough as it is for beginners.
>>> 
>>> 
>>> But just for my understanding: There is no better solution if
>>> (unrelated) changes come in while I implement small changes myself,
>>> right? I'm basically looking for anything similar to an "svn update"
>>> which doesn't involve a new commit, such that the commit log remains
>>> "readable"?
>> 
>> 
>> While you have not checked in, hg up works the same as svn up. When you
>> already have committed changesets, they will not be automatically
>> inserted in a linear fashion. Rebase is the thing to do if you prefer
>> linear histories. I have no strong opinion wither way, the "bubbly"
>> style works fine, too. Of course it also makes sense to pull and update
>> before starting something new.
>> 
>> 
>>> I guess one could just be quick enough with committing to avoid
>>> crossing each other,
>> 
>> 
>> No, that won't help anyway. No matter how fast you are, your commits
>> won't be on the other person's clone and theirs won't be on your clone
>> until you pull.
>> 
>> 
>>> So the choice is between messy commit logs or non-default features
>>> (rebase)?
>> 
>> 
>> Rebase comes with the default HG, it just needs to be enabled
>> explicitly, because some house rules forbid its use, because it breaks
>> the "history must never change" principle of HG. Rebase allows history
>> changes on parts of history that so far only you can see.
>> 
>> 
>>>> You pushed two changesets, your commit eb4c2 and the merge 08fb55.
>>>> Were you expecting others?
>>> 
>>> 
>>> That's the other thing which confused me: The history in my local
>>> repo looks different! Even after pull and update, my local history
>>> has my actual commit (eb4c2, which is r4014 in the central repo) at
>>> r3958, which is why I didn't see it at first. I understand that
>>> these discrepancies are temporarily present in a distributed VCS, but
>>> I always thought that after pushing, pulling and updating everything
>>> will be identical. Seems like not.
>> 
>> 
>> That's a misunderstanding here: There is never an unresolvable
>> discrepancy. Everything _is_ always identical, because the only thing
>> that matters is the topology of the changesets. The hex hash values
>> are the changeset identifier. The number before the hash is a _local_
>> count of changesets that you have pulled/committed in the order that
>> they were done locally on that clone. This numbering will always differ
>> between different actively developing clones.
>> 
>> When you pull, you bring in changesets that you don't have yet, numbered
>> onwards from wherever you got to, but each one of them has a specific
>> unique unchangeable place in your revision tree topology.
>> Every node in the topology has exactly 1 or 2 parents (node 0 has 0 of
>> course), but each node can have arbitrarily many children. In the
>> implementation of hg it's the parent linkage (visible in 'hg summary' and
>> 'hg log -v') that determines the topology.
>> 
>> 
>>> Anyway, I'm slowly starting to feel like I can use it now.
>> 
>> 
>> Please keep asking! It's useful for others, too. I blame this whole
>> confusion on CVS/SVN's broken concept of revisions. :-)  People who
>> start on hg/git right away don't come across these questions.
>> 
>> 
>>> sorry for making the commit log look more complicated than
>>> necessary!
>> 
>> 
>> The log is absolutely fine, nothing wrong with it. Every clone is
>> naturally also a fork, so loops like this in the history are normal [1].
>> 
>> See you,
>> 
>>  David
>> 
>> 
>> [1] There is actually a commit style where bugfixes for a broken line in
>> an old commit should happen as a child node of that ancient version, and
>> be merged from there to the top. That way, it is visible in the commit
>> graph which revisions were potentially affected by the bug. That one is a
>> bit too much for my taste, but hg allows this style quite naturally.
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet