Main Area and Open Discussion > General Software Discussion

DVCS ? (All about Git, Mercurial-Hg and the like...)

(1/39) > >>

Armando:
DVCS : what system to you use... And why ? I'm also generally curious about the context in which you use it (e.g. : working alone or in a team ? purely for code  ?)...

===

Some background info ?

There's been several discussions about version control systems here, but only a few about DVCS and its open systems (Git, Mercurial...). I admit I installed Tortoise SVN a while ago and never used it. Instead I rely on a few different tools like AutoVer, time stamped backups, notes, etc.

I'm currently working on a coding project (my first "real" one in fact), and am wondering if I should be more rigorous about version control etc. But since I have perfectionist tendencies and tend to loose time on details and unnecessary stuff, I want to avoid getting into something that might be very interesting (no doubt...) BUT that will slow me down for months without giving me any concrete benefits. So... if you have any advice concerning that matter... Thanks. :)

Ath:
... But since I have perfectionist tendencies...
-Armando (February 19, 2011, 02:39 PM)
--- End quote ---
With that said: Do get some kind of VCS!

If working alone or in a small local team (in the same office): Get SVN, it's easy to set up (locally) and very well documented.
If working in a geographically 'wide area' or a large group of people, get GIT or Mercurial and a hosted central server, or create a project at SourceForge with SVN if somebody really wants that to be used.

Armando:
Thanks for taking the time to answer. I was thinking of getting acquainted with Tortoise SVN (as I said, it's already installed on my computer, etc.). But then I read comments (mainly from f0dder) about GIT, Mercurial and the like... and how annoying SVN could become in some contexts.

Since all these version control systems seem to take a fair number of hours to get truly familiar with their mechanism and features, I just want to make sure I don't uselessly invest time in a one of them to discover I should've invested energy in "the another one".

So... From what you say ("If working alone or in a small local team (in the same office)"), I should just start working with I've got installed : tortoise SVN. Does that mean that GIT or Mercurial aren't good for these contexts (or not worth the effort) ?

mwb1100:
I mainly use SVN right now.  If I were starting from nothing, I think I'd consider Mercurial over SVN - it seems less complex than Git and seem a bit more Windows friendly.  TortoiseHg seems to be as featured as TortoiseSVN (and I think that this is a testament to the TortoiseSVN project, since I think that TortoiseHg used that as a starting point).  I'm considering converting my personal SVN repository to Mercurial, and hosting it on https://bitbucket.org/ where you can have free private repositories.  If bitbucket ever goes away, that's not a big deal since any workspace I have is essentially a full backup of the repository.  Moving my hosted SVN stuff was a bit of a pain when my 1st hoster dropped their free plans.

I think that for most projects (even with a DVCS), you'll still likely have a central 'repository of record' (where your official builds will work from), but I think the especially in a single user or very small team environment, not needing a central server can be really nice.

If you're going to be working on Linux kernel stuff, Git is the obvious choice.

All that said, SVN is still a fine choice, and if you're going to be working with a team that's already familiar with it, I'd lean in that direction.

f0dder:
OK, there's several things to address here.

First things first: get some version control, right now. Even if you're never going to collaborate with other people, you'll learn to appreciate it. VCS serves as part of a backup scheme, it's easier to find particular versions of your source code than dealing with timestamped copies, and once you become disciplined and write proper commit messages and commit at a proper granularity, you'll see you have some powerful tools at hand to search history, track regressions, managed branches et cetera. It does take a bit getting really used to VCS and reap all the benefits, but it's worth investing time in it.

Next, move to either Mercurial or Git right away, go right past Subversion and don't collect the... oh wait, this isn't monopoly. But do avoid svn even if you aren't going to use the distributed features of Hg or Git. Why? If nothing else, speed. A list:


* Fetching the entire Notepad++ Community Release wia Git via my 20mbit ADSL is faster than grabbing fSekrit with subversion on my gigabit LAN. Nuff' said?
* Since dvcs store all files locally in addition to the (optional) remote repository, switching branches or datamining history is lightning fast. With subversion, even on a gigabit lan some operations can be painfully slow.
* Subversion stores it's info in ".svn" folders in each and every subfolder of your project. This is ugly, it means you have to use "svn export" to grab/export a clean subtree, and if you forget to do this and copy subfolders around in your svn-managed project, you can screw things up majorly. Both Hg and Git use a single top-level folder per project.
* Even though subversion has metadata scattered in all those .svn folders, you don't have the full project history locally - so if your remote repository goes AWOL, you're screwed. With Hg and Git, your own machine has a full local copy of all history.
* Subversion doesn't treat branches and tags specially, but just as part of the filesystem. This does, kinda, give you some flexibility, but it's flex you don't need, and it can cause a lot of clutter and fuss if you aren't very disciplined with how you arrange stuff.
* Branches in svn always go to your repository, meaning they're slightly slow operations to perform, they "pollute" the namespace, etc. Thus, with svn, you think a lot before you make a branch, especially on a multi-dev project. With Hg and Git, you can do local "feature branches" to work on without disturbing other people, and merge those to the current working branch before pushing your changes upstream. In other words, YOU have a lot of flexibility on your own machine, without necessarily cluttering things for everybody else. Even on single-dev projects, it's nice being able to take a break from adding a new feature to fix a bug, and then merge it all together.
Tortoise is available for Mercurial as well as Git, even if not entirely as polished as TortoiseSvn. Git is probably the system that feels least polished at the moment, but it's entirely usable.

I'm not sure which one to recommend, though. Git does have all the geekboypowerhead features, and you can definitely blast off your legs with the command line tool...  But if you stick with basic features, it's really not that bad. Both Hg and Git can be used for pretty much the same workflow as you have with Subversion, so IMHO there's not much use to stick with svn unless you have to for interop reasons.

You should probably start by checking out Mercurial and TortoiseHg. Chances are you won't need to look at any of the other projects after that. And if you stay clear of svn, you won't need to muck around with converting your repositories when you feel like ditching it at some later point :)

Navigation

[0] Message Index

[#] Next page