On 29/01/2011 10:02, "Jérôme M. Berger" wrote:
Michel Fortin wrote:
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.
Mercurial can record renamed or copied files after the fact (simply
pass the -A option to "hg cp" or "hg mv"). It also has the
"addremove" command which will automatically remove any missing
files and add any unknown non-ignored files. Addremove can detect
renamed files if they are similar enough to the old file (the
similarity level is configurable) but it will not detect copies.
Jerome
Indeed, that's want I found out now that I tried Mercurial. So that's
really nice (especially the "addremove" command), it's actually
motivation enough for me to switch to Mercurial or Git, as it's a major
annoyance in SVN.
I've learned a few more things recently: there's a minor issue with Git
and Mercurial in that they both are not able to record empty
directories. A very minor annoyance (it's workaround-able), but still
conceptually lame, I mean, directories are resources too! It's curious
that the wiki pages for both Git and Mercurial on this issue are exactly
the same, word by word most of them:
http://mercurial.selenic.com/wiki/MarkEmptyDirs
https://git.wiki.kernel.org/index.php/MarkEmptyDirs
(I guess it's because they were written by the same guy)
A more serious issue that I learned (or rather forgotten about before
and remembered now) is the whole DVCSes keep the whole repository
history locally aspect, which has important ramifications. If the
repository is big, although disk space may not be much of an issue, it's
a bit annoying when copying the repository locally(*), or cloning it
from the internet and thus having to download large amounts of data.
For example in the DDT Eclipse IDE I keep the project dependencies
(https://svn.codespot.com/a/eclipselabs.org/ddt/trunk/org.dsource.ddt-build/target/)
on source control, which is 141Mb total on a single revision, and they
might change ever semester or so...
I'm still not sure what to do about this. I may split this part of the
project into a separate Mercurial repository, although I do lose some
semantic information because of this: a direct association between each
revision in the source code projects, and the corresponding revision in
the dependencies project. Conceptually I would want this to be a single
repository.
(*) Yeah, I know Mercurial and Git may use hardlinks to speed up the
cloning process, even on Windows, but that solution is not suitable to
me, as I my workflow is usually to copy entire Eclipse workspaces when I
want to "branch" on some task. Doesn't happen that often though.
--
Bruno Medeiros - Software Engineer
