3 ms·

I've only lived through one version control migration, that was from TFS to Subversion. The problem we have is the length of time Subversion takes doing updates

I've only lived through one version control migration, that was from TFS to Subversion. The problem we have is the length of time Subversion takes doing updates, commits, and merges when you are dealing with a large repository and many changes spread out among files. (Good old TFS was fast.) Can anyone say if Mercurial is significantly faster? After going through Joel's tutorial it looks like Mercurial keeps history from branches in the root much better than either TFS or Subversion. I think I would opt for Mercurial the next time I have to set up source control.

j_baker 17y ago
Try out git. Force yourself to use it for a few weeks. I didn't like it at first. I used to be a Mercurial guy until I really learned git. I still don't know what it is, but there's something about git that just makes me want to love it.
kneath 17y ago
I can say without hesitation mercurial or git will be insanely faster for these operations. Remember, you work locally, and then push with hg/git. So when you do "git commit" it only relies on the speed of your hard drive/cpu. Commits happen instantly. Updates are needed very rarely (since you don't need to update to make new commits). Merges are so much faster it's not even funny. After merging in hg/git you wonder why SVN even had a merge functionality. In addition to those conceptual differences, the actual act of transferring files between remote and local on git/hg is also much faster than SVN. Entire checkouts of git repositories are usually smaller (disk size) than the equivalent SVN checkout... of one version. This means less time on the network all around.
- jackfoxy 17y ago
  Yeah, committing to your local copy better be fast, it's committing to the shared server repository that I'm concerned about.
  - chousuke 17y ago
    I think you'll find that whatever git does, it's faster than the corresponding operation in SVN. When you send commits to a remote server, git compresses them and sends the packfile over the network. The server will refuse non-fast forward merges (the branch you're pushing is supposed to be merged by you first, locally) so it pretty much has nothing to do but uncompress the changes and apply them. Unless you have a really slow network or are sending an insane number of commits, it's not going to take longer than a few seconds. Cloning big repositories (like emacs, with ~25 years of history) can take a while if you have a slow network, but sometimes it feels like git can actually clone a repository faster than SVN can check out a single revision. But repos like emacs' are rare. Often, SVN repositories end up being huge because they contain the code of many unrelated projects. In Git, having such a huge repository is impractical; each project should have its own repository. There is support for submodules though, so you can make a "master" repo that contains pointers to the child repositories, if you really have to.

j_baker 17y ago

Try out git. Force yourself to use it for a few weeks. I didn't like it at first. I used to be a Mercurial guy until I really learned git. I still don't know what it is, but there's something about git that just makes me want to love it.

kneath 17y ago

I can say without hesitation mercurial or git will be insanely faster for these operations. Remember, you work locally, and then push with hg/git. So when you do "git commit" it only relies on the speed of your hard drive/cpu. Commits happen instantly. Updates are needed very rarely (since you don't need to update to make new commits). Merges are so much faster it's not even funny. After merging in hg/git you wonder why SVN even had a merge functionality. In addition to those conceptual differences, the actual act of transferring files between remote and local on git/hg is also much faster than SVN. Entire checkouts of git repositories are usually smaller (disk size) than the equivalent SVN checkout... of one version. This means less time on the network all around.

jackfoxy 17y ago
Yeah, committing to your local copy better be fast, it's committing to the shared server repository that I'm concerned about.
- chousuke 17y ago
  I think you'll find that whatever git does, it's faster than the corresponding operation in SVN. When you send commits to a remote server, git compresses them and sends the packfile over the network. The server will refuse non-fast forward merges (the branch you're pushing is supposed to be merged by you first, locally) so it pretty much has nothing to do but uncompress the changes and apply them. Unless you have a really slow network or are sending an insane number of commits, it's not going to take longer than a few seconds. Cloning big repositories (like emacs, with ~25 years of history) can take a while if you have a slow network, but sometimes it feels like git can actually clone a repository faster than SVN can check out a single revision. But repos like emacs' are rare. Often, SVN repositories end up being huge because they contain the code of many unrelated projects. In Git, having such a huge repository is impractical; each project should have its own repository. There is support for submodules though, so you can make a "master" repo that contains pointers to the child repositories, if you really have to.