On 2011-01-28 11:29:49 -0500, Bruno Medeiros
<brunodomedeiros+spam@com.gmail> said:
I've also been mulling over whether to try out and switch away from
Subversion to a DVCS, but never went ahead cause I've also been
undecided about Git vs. Mercurial. So this whole discussion here in the
NG has been helpful, even though I rarely use branches, if at all.
However, there is an important issue for me that has not been mentioned
ever, I wonder if other people also find it relevant. It annoys me a
lot in Subversion, and basically it's the aspect where if you delete,
rename, or copy a folder under version control in a SVN working copy,
without using the SVN commands, there is a high likelihood your working
copy will break! It's so annoying, especially since sometimes no amount
of svn revert, cleanup, unlock, override and update, etc. will fix it.
I just had one recently where I had to delete and re-checkout the whole
project because it was that broken.
Other situations also seem to cause this, even when using SVN tooling
(like partially updating from a commit that delete or moves
directories, or something like that) It's just so brittle.
I think it may be a consequence of the design aspect of SVN where each
subfolder of a working copy is a working copy as well (and each
subfolder of repository is a repository as well)
Anyways, I hope Mercurial and Git are better at this, I'm definitely
going to try them out with regards to this.
Git doesn't care how you move your files around. It track files by
their content. If you rename a file and most of the content stays the
same, git will see it as a rename. If most of the file has changed,
it'll see it as a new file (with the old one deleted). There is 'git
mv', but it's basically just a shortcut for moving the file, doing 'git
rm' on the old path and 'git add' on the new path.
I don't know about Mercurial.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
