Talk:Mercurial vs. Subversion

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Details about Mercurial's behaviour)
Line 3: Line 3:
Not exactly. Mercurial would record the two changes as separate heads (implicit branches). And, by default, it would not allow pushing both to a central repo without a prior merge. But this is just a default. What typically bothers people is they need to merge the two heads to combine their effects. Which is, again, correct, but may seem to clutter history. So you can rebase, if you prefer, explicitly emulating what svn implicitly does.
Not exactly. Mercurial would record the two changes as separate heads (implicit branches). And, by default, it would not allow pushing both to a central repo without a prior merge. But this is just a default. What typically bothers people is they need to merge the two heads to combine their effects. Which is, again, correct, but may seem to clutter history. So you can rebase, if you prefer, explicitly emulating what svn implicitly does.
-parren
-parren
 +
 +
Interesting note. Thanks. I copied it to [[Mercurial vs. Subversion|main page]]. Feel free to edit it there. One question through. What you mean by ''rebase''. I only found [[Git]]'s rebase, but nothing for [[Mercurial]]. I know I can do:
 +
 +
<script lang="bash">
 +
# with some local changes
 +
hg pull -u
 +
hg ci -m "..."
 +
hg push
 +
</script>
 +
 +
and effectively do ''rebase'' before single commit. Or, in case I've already integrated my commit I can:
 +
<script lang="bash">
 +
hg push # fails and I do not want 2nd head
 +
hg rollback
 +
hg pull -u
 +
hg ci -m "..."
 +
hg push
 +
</script>
 +
 +
But how exactly do ''rebase'' for multiple commits is not really clear to me. Maybe with ''hg strip''?

Revision as of 04:36, 10 April 2009

<quote>Mercurial would refuse such integration asking the user A to svn update to latest version of the repository first. This is the correct behaviour. However it is not really clueless.</quote>

Not exactly. Mercurial would record the two changes as separate heads (implicit branches). And, by default, it would not allow pushing both to a central repo without a prior merge. But this is just a default. What typically bothers people is they need to merge the two heads to combine their effects. Which is, again, correct, but may seem to clutter history. So you can rebase, if you prefer, explicitly emulating what svn implicitly does. -parren

Interesting note. Thanks. I copied it to main page. Feel free to edit it there. One question through. What you mean by rebase. I only found Git's rebase, but nothing for Mercurial. I know I can do:

<script lang="bash">

  1. with some local changes

hg pull -u hg ci -m "..." hg push </script>

and effectively do rebase before single commit. Or, in case I've already integrated my commit I can: <script lang="bash"> hg push # fails and I do not want 2nd head hg rollback hg pull -u hg ci -m "..." hg push </script>

But how exactly do rebase for multiple commits is not really clear to me. Maybe with hg strip?

Personal tools
buy