You're right--this is not the right place for questions like that. That being said, might as well answer your questions..
First things first: Git and Mercurial are different beasts. You'll see them clumped together in most cases because they're both "distributed version control systems." To put it simply, the main difference between these kinds of VCS and the non-distributed ones like SVN is that with a distributed vcs, each copy is a full repo. (you can find out more about that by reading up). Git and Hg share similar concepts, but they have different interfaces and philosophies, so they're quite different. With that in mind, I'm gonna answer your questions from a Git point of view, since it's what we use. Short answer: no, Git doesn't care about the top-level folder. Unlike SVN, Git only creates one 'internal' folder for the whole repo, which is '.git' and is found at the root of your repo. When the containing folder changes (renamed, moved, etc.), Git will still work, because the internal folder is unmoved, and because like I said above, each clone of a git repository (aka, each copy/clone of the initial repo), is a full git repo on its own (i.e: you can commit, push, pull and clone from a working copy). Another important difference: Git doesn't track files, it tracks the *content* of files. Say you have a file in your repo called 'one.txt' and you deleted that file, replaced it with another file of the same name and exact same contents. Other vcs will bark at you, because they're tracking the file itself. But Git won't care--as long as the files have the same content, Git treats them as the same file. As for speed concerns, your mileage may vary, although it might speed you up in some places. No matter what vcs you're using, the initial cloning will always be slow for big repos because you're downloading the whole history and all associated files. In the case of Git though, it's gonna be slightly faster because it doesn't litter your whole repo with internal folders (no '.git' folders everywhere, just one-- unlike .svn) and in most cases, you'll be using the Git transfer protocol which is designed for efficiency. Another speed boost in terms of workflow would be commits--since commits are done locally before pushing them to your main repo. You'll find yourself committing stuff more often (and that's a great thing) and them pushing all of your commits at once, shaving off a lot of time in the transfer process. Best of all, branching and merging are easier in Git. Torvalds designed Git to make these things waaaay easier than SVN (Linus hates CVS and SVN with a passion shamed only by his loathing of C++). Finally, if you're choosing between Git and Mercurial, then you're not gonna commit big mistakes. Both are great systems and both have big, helpful communities to back them up. Git has Github and Mercurial has, err, BitBucket. Git is written in C and Mercurial is in Python. They're both fast, but Git excels in branching and merging (and it has its own transfer protocol that speeds things up). Good luck. K.O http://keetology.com/ On Dec 5, 5:19 pm, stratboy <[email protected]> wrote: > Hi! I know this is not the right place for questions like this. I try > anyway :) > > I'm totally new to version control. I'm trying subversion. The main > (maybe the only one) thing I don't like is that if I rename a > repository or a direcotry containing the repo, then my working copy > can't commit changes anymore. The same if I rename a working copy. > So, I see mootools uses Git. Does Git have the same renaming/moving > problems? And Mercurial? Is there any versioning system that let you > do that? > > Another little question: I'm a programmer and a designer as well. So > my project folders often are quite big. And subversion is really slow > in importing them and creating a working copy. So is git better in > this? And Mercurial? > > I read the docs of git and mercurial but I'm not able to desume this > kind of info. > > Thanks for any help
