Bruno Medeiros Wrote: > 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
You raised a valid concern regarding the local copy issue and it has already been taken care of in DVCSes: 1. git stores all the actual data in "blobs" which are compressed whereas svn stores everything in plain-text (including all the history!) 2. git stores and transfers deltas and not full files unlike svn 3. it's possible to wrap a bunch of commits into a "bundle" - a single compressed binary file. This file can be than downloaded and than you can git fetch from it. In general Git (and I assume mercurial as well) both needs way less space than comparable SVN repositories and is much faster in fetching from upstream compared to svn update. Try cloning your svn repository with git-svn and compare repository sizes..
