Mercurial vs. Subversion - Revision history

JaroslavTulach: /* Mercurial vs. Subversion */

JaroslavTulach — Mon, 09 Aug 2010 13:20:36 GMT

Mercurial vs. Subversion

←Older revision		Revision as of 13:20, 9 August 2010
Line 30:		Line 30:
	</source>		</source>

-	The significant difference between [[Subversion]] and [[Mercurial]] is really there. [[Subversion]] lets the user A integrate changes without knowing what the final state after the integration will be. Seen from rationalistic point of view, this is not ''correct'' at all.	+	The significant difference between [[Subversion]] and [[Mercurial]] is really there. [[Subversion]] lets the user A integrate changes without knowing what the final state after the integration will be. Seen from [[Rationalism\|rationalistic]] point of view, this is not ''correct'' at all.

	[[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 [[cluelessness\|clueless]].		[[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 [[cluelessness\|clueless]].

82.67.117.220: /* Implicit Merges */ linking to the appropriate page about rebase

82.67.117.220 — Sun, 12 Jul 2009 09:21:56 GMT

Implicit Merges: linking to the appropriate page about rebase

←Older revision		Revision as of 09:21, 12 July 2009
Line 42:		Line 42:
	In case of parallel integrations [[Mercurial]] would record the two changes as separate heads (implicit branches). And it would not allow pushing both to a central repo without a prior merge (by default).		In case of parallel integrations [[Mercurial]] would record the two changes as separate heads (implicit branches). And it would not allow pushing both to a central repo without a prior merge (by 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 [http://~~www~~.~~kernel~~.~~org~~/~~pub~~/~~software/scm/git-core/docs/git-~~rebase~~.html rebase] (Jaroslav's note: rebase works only in [[git]~~]~~, doesn't it?)~~, if you prefer, explicitly emulating what [[Subversion]] implicitly does.	+	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 [http://mercurial.selenic.com/wiki/RebaseExtension rebase], if you prefer, explicitly emulating what [[Subversion]] implicitly does.

JaroslavTulach: /* Implicit Merges */

JaroslavTulach — Fri, 10 Apr 2009 04:40:26 GMT

Implicit Merges

←Older revision		Revision as of 04:40, 10 April 2009
Line 40:		Line 40:
	As [[Talk:Mercurial_vs._Subversion\|parren wrote]] the cause why [[Mercurial]] work flow is more complex lies in the concept of explicit merges.		As [[Talk:Mercurial_vs._Subversion\|parren wrote]] the cause why [[Mercurial]] work flow is more complex lies in the concept of explicit merges.

-	In case of ~~conflict~~ [[Mercurial]] would record the two changes as separate heads (implicit branches). And it would not allow pushing both to a central repo without a prior merge (by default).	+	In case of parallel integrations [[Mercurial]] would record the two changes as separate heads (implicit branches). And it would not allow pushing both to a central repo without a prior merge (by 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 [http://www.kernel.org/pub/software/scm/git-core/docs/git-rebase.html rebase] (Jaroslav's note: rebase works only in [[git]], doesn't it?), if you prefer, explicitly emulating what [[Subversion]] implicitly does.		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 [http://www.kernel.org/pub/software/scm/git-core/docs/git-rebase.html rebase] (Jaroslav's note: rebase works only in [[git]], doesn't it?), if you prefer, explicitly emulating what [[Subversion]] implicitly does.

JaroslavTulach at 04:30, 10 April 2009

JaroslavTulach — Fri, 10 Apr 2009 04:30:33 GMT

←Older revision		Revision as of 04:30, 10 April 2009
Line 35:		Line 35:

	Enormous majority of developers I know is complaining about such [[Mercurial]] restrictions. This is another example of ''correct but complex'' behaviour. Such correctness is reached at the expense of usability. Nice illustration of what can happen when one strives to make an [[API has to be Correct\|API correct]] while ignoring other aspects of [[Good Technology\|Good API]].		Enormous majority of developers I know is complaining about such [[Mercurial]] restrictions. This is another example of ''correct but complex'' behaviour. Such correctness is reached at the expense of usability. Nice illustration of what can happen when one strives to make an [[API has to be Correct\|API correct]] while ignoring other aspects of [[Good Technology\|Good API]].
		+
		+	=== Implicit Merges ===
		+
		+	As [[Talk:Mercurial_vs._Subversion\|parren wrote]] the cause why [[Mercurial]] work flow is more complex lies in the concept of explicit merges.
		+
		+	In case of conflict [[Mercurial]] would record the two changes as separate heads (implicit branches). And it would not allow pushing both to a central repo without a prior merge (by 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 [http://www.kernel.org/pub/software/scm/git-core/docs/git-rebase.html rebase] (Jaroslav's note: rebase works only in [[git]], doesn't it?), if you prefer, explicitly emulating what [[Subversion]] implicitly does.

JaroslavTulach: /* Mercurial vs. Subversion */

JaroslavTulach — Sun, 05 Apr 2009 16:32:52 GMT

Mercurial vs. Subversion

←Older revision		Revision as of 16:32, 5 April 2009
Line 30:		Line 30:
	</source>		</source>

-	~~This is a~~ significant difference between [[Subversion]] and [[Mercurial]]. [[Subversion]] lets the user A integrate changes without knowing what the final state after the integration will be. Seen from rationalistic point of view, this is not ''correct''. [[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 [[cluelessness\|clueless]] ~~and enormous~~ majority of developers I know is complaining about such [[Mercurial]] restrictions. This is another example of ''correct but complex'' behaviour. Such correctness is reached at the expense of usability. Nice illustration of what can happen when one strives to make an [[API has to be Correct\|API correct]].	+	The significant difference between [[Subversion]] and [[Mercurial]] is really there. [[Subversion]] lets the user A integrate changes without knowing what the final state after the integration will be. Seen from rationalistic point of view, this is not ''correct'' at all.
		+
		+	[[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 [[cluelessness\|clueless]].
		+
		+	Enormous majority of developers I know is complaining about such [[Mercurial]] restrictions. This is another example of ''correct but complex'' behaviour. Such correctness is reached at the expense of usability. Nice illustration of what can happen when one strives to make an [[API has to be Correct\|API correct]] while ignoring other aspects of [[Good Technology\|Good API]].

JaroslavTulach: /* Mercurial vs. Subversion */

JaroslavTulach — Sun, 05 Apr 2009 16:30:32 GMT

Mercurial vs. Subversion

←Older revision		Revision as of 16:30, 5 April 2009
Line 12:		Line 12:
	<source lang="bash">		<source lang="bash">
	# create a new file as user A:		# create a new file as user A:
-	svn co file://~~/home/jarda~~/tmp/svn/r/	+	svn co file:///tmp/svn/r/
	echo Hi. >readme.txt		echo Hi. >readme.txt
	svn add readme.txt		svn add readme.txt
Line 18:		Line 18:

	# create another new file as user B:		# create another new file as user B:
-	svn co file://~~/home/jarda~~/tmp/svn/r/	+	svn co file:///tmp/svn/r/
	echo >b.txt		echo >b.txt
	svn add b.txt		svn add b.txt

JaroslavTulach: /* Mercurial vs. Subversion */

JaroslavTulach — Sun, 05 Apr 2009 16:23:37 GMT

Mercurial vs. Subversion

←Older revision		Revision as of 16:23, 5 April 2009
Line 9:		Line 9:
	: '''I'm trying to commit, but Subversion says my working copy is out of date?''', answer 3.		: '''I'm trying to commit, but Subversion says my working copy is out of date?''', answer 3.

-	Looks like sometimes the '''svn up''' is needed. However not in regular workflow. I've just tried:	+	Looks like sometimes the '''svn up''' is needed. However not in the regular workflow. I've just tried:
	<source lang="bash">		<source lang="bash">
	# create a new file as user A:		# create a new file as user A:

JaroslavTulach: New page: == Mercurial vs. Subversion == One side note in the chapter 13 compares behaviour of Mercurial and Subversion. A curious reader sent a commen...

JaroslavTulach — Sun, 05 Apr 2009 16:22:56 GMT

New page: == Mercurial vs. Subversion == One side note in the chapter 13 compares behaviour of Mercurial and Subversion. A curious reader sent a commen...

New page

== Mercurial vs. Subversion ==

One side note in the [[Extreme_Advice_Considered_Harmful|chapter 13]] compares behaviour of [[Mercurial]] and [[Subversion]]. A curious reader sent a comment:

: Page 241: In the scenario described [[Subversion]] behaves the same way as [[Mercurial]],
: so it would not be possible to checkin changes without first synchronizing against
: the HEAD revision (assuming checking goes to HEAD). See, for instance,
: [http://subversion.tigris.org/faq.html Subversion FAQ], question
: '''I'm trying to commit, but Subversion says my working copy is out of date?''', answer 3.

Looks like sometimes the '''svn up''' is needed. However not in regular workflow. I've just tried:
<source lang="bash">
# create a new file as user A:
svn co file:///home/jarda/tmp/svn/r/
echo Hi. >readme.txt
svn add readme.txt
svn ci -m "adding readme.txt by user A"

# create another new file as user B:
svn co file:///home/jarda/tmp/svn/r/
echo >b.txt
svn add b.txt
svn ci -m "Adding file b.txt from user B"

# now, as user A change the readme file, without updating
# e.g. without knowing that there is the b.txt file:
echo Hello >readme.txt
svn diff
svn ci -m "Changing content of file readme.txt as A, without updating to B's latest version"
</source>

This is a significant difference between [[Subversion]] and [[Mercurial]]. [[Subversion]] lets the user A integrate changes without knowing what the final state after the integration will be. Seen from rationalistic point of view, this is not ''correct''. [[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 [[cluelessness|clueless]] and enormous majority of developers I know is complaining about such [[Mercurial]] restrictions. This is another example of ''correct but complex'' behaviour. Such correctness is reached at the expense of usability. Nice illustration of what can happen when one strives to make an [[API has to be Correct|API correct]].