[Rivet] HG transition

[David Grellscheid]

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.