Am 28.02.2010 um 12:58 schrieb Ingo Weinhold:
On 2010-02-28 at 11:07:28 [+0100], Andreas Färber <andreas.faerber@xxxxxx >wrote:To my knowledge and past experience, Git used to be the most suited for tracking an SVN repository - personally or for a future switch - whereas Mercurial only imported single snapshots rather than the complete SVN history.You are mistaken. E.g. our read-only mercurial repository at http://hg.haiku-os.org/haiku/haiku-trunk has the complete history.
So here's the problem: I do: hg clone http://hg.haiku-os.org/haiku/haiku-trunk haikuFine. I want APM and ACPI enabled, so I change the settings file and do a local commit:
hg commit -m "Enable APM and ACPI" Working great like in Git so far.However, every now and then I want to update my tree but keep my local changes. According to the tutorials I read I'm supposed to do:
hg pull hg update hg merge http://mercurial.selenic.com/wiki/CvsLikePracticeThat's not what I want. Because now, for every update I need to enter a merge commit message, which I see in my local log, so that the changeset numbers start drifting apart. With git-svn, I simply do:
git svn rebaseand I get a clean SVN history on my branch plus my local change on top, with no additional steps if there are no conflicts.
http://www.kernel.org/pub/software/scm/git/docs/git-svn.htmlIf I want to send out my local changes, I can do: git format-patch remotes/trunk
The Mercurial workflow above would seem to better resemble: git svn fetch git merge remotes/trunk leaving me with a mixture of remote and local changes. hg outgoingshows me lots of unnecessary merge changesets in addition to the one actual change and I see no command to clean this up.
Am I doing something terribly wrong, or is there no concept of rebasing as opposed to merging in Mercurial?
Andreas