[Rivet] HG transition

[Frank Siegert]

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.