DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

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 at 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