326

I am starting a new distributed project. Should I use SVN or Git, and why?

Cole Tobin
  • 9,206
  • 15
  • 49
  • 74
rudigrobler
  • 17,045
  • 12
  • 60
  • 74
  • 5
    Yes, git works on Mac. If you use macports to install it, it will even install a mac front end to the commit and browse interfaces. – Seth Johnson Mar 30 '10 at 22:36
  • 3
    possible duplicate of http://stackoverflow.com/questions/871/why-is-git-better-than-subversion –  Mar 30 '10 at 22:37
  • 3
    @Andre - because you can use MonoDevelop -- I switch from Vault to SVN so that I can develop .NET software on my mac or pc. There was no client for Vault but there was for SVN :-) – schmoopy Sep 01 '11 at 17:41
  • see also http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-be-the-future-of-revision-control/ – naught101 Mar 13 '12 at 10:47
  • 4
    Github/bitbucket + sourcetree = heaven! - http://www.sourcetreeapp.com/ – thecodeassassin May 09 '12 at 10:02
  • As of 2013, I switched from SVN to TFS to Git, and a lot of Git clients are made available nowadays. Window is no longer a second class to Git world. – OKEEngine Mar 17 '13 at 23:50
  • SourceTree is excellent for Windows or Mac and can be used for any Git repo – DarVar Jun 18 '13 at 13:17
  • error: File is 123.23 MB; this exceeds GitHub's file size limit of 100 MB !!!! – Fuzzy Analysis Dec 27 '13 at 04:53
  • For me it's Git EVERYTIME except if you manage assets that you really can't manage without exclusive checkout or that are very bigs. – Philippe Feb 03 '14 at 17:09
  • If you don't want to start pulling your hair out after sometime, use Git. with SVN you will literarily piss blood. currently the project that am working on uses SVN and i hate every moment i have to type svn in my terminal – Udo Aug 07 '15 at 17:48
  • **Subversion for binary files** (e.g. powerpoint, excels, word files ) , **Git for text files** (e.g. Java files ) – kenju Aug 24 '15 at 04:59

21 Answers21

255

SVN is one repo and lots of clients. Git is a repo with lots of client repos, each with a user. It's decentralised to a point where people can track their own edits locally without having to push things to an external server.

SVN is designed to be more central where Git is based on each user having their own Git repo and those repos push changes back up into a central one. For that reason, Git gives individuals better local version control.

Meanwhile you have the choice between TortoiseGit, GitExtensions (and if you host your "central" git-repository on github, their own client – GitHub for Windows).

If you're looking on getting out of SVN, you might want to evaluate Bazaar for a bit. It's one of the next generation of version control systems that have this distributed element. It isn't POSIX dependant like git so there are native Windows builds and it has some powerful open source brands backing it.

But you might not even need these sorts of features yet. Have a look at the features, advantages and disadvantages of the distributed VCSes. If you need more than SVN offers, consider one. If you don't, you might want to stick with SVN's (currently) superior desktop integration.

BuZZ-dEE
  • 6,075
  • 12
  • 66
  • 96
Oli
  • 235,628
  • 64
  • 220
  • 299
  • 25
    Might also have a look at Hg (Mercury) – Joel Mar 30 '10 at 22:24
  • 1
    Native builds, if using a scripting language is considered native... By the same logic, Git is native - it just needs a program (cygwin or msys) to run it. – alternative Aug 25 '10 at 23:47
  • 24
    Things have gotten much better since October 2008. You can install TortoiseGit, grab the latest portable version of MSysGit, and tell TortoiseGit where to find it. I just moved my big svn repo over to git today because svn's poor renaming support finally made me mad enough. – We Are All Monica Sep 24 '10 at 19:37
  • 4
    Moving on 2 years we now have some good windows tools. Currently I'm using netbeans with MSysGit. I've also had good luck with TortoiseGit. I think it's good enough to be used in production. Considering how hard it is to manage simple conflicts in subversion git is a huge improvement. – Benbob Oct 27 '10 at 01:19
  • 24
    We use Git on Windows heavily and have for a long time now. Git is absolutely fantastic on Windows. – Charlie Flowers Feb 06 '11 at 05:18
  • 13
    @Oli Would be good to update your answer (esp about Windows git client) based on the comments here and your experience. The current answer seems biased now that 2-3 years have passed since it was written. – amit kumar May 16 '11 at 03:27
  • @Charlie Flowers With that type of client? – ptomasroos Sep 15 '11 at 15:24
  • 3
    @Tomas Roos - we have mostly used the command line along with gitk (a limited graphical tool that comes with git). There are only about 5 commands you need on a daily basis, and its simple and powerful. Give everyone a cheat sheet, and let them call over an expert in those cases where something unusual is going on. Within a month, they'll be able to handle the unusual cases without help too. – Charlie Flowers Sep 21 '11 at 14:38
  • Your only complaint seems to be that Git doesn't have a good GUI on windows. Can I take this to mean that, in your opinion, SVN is still the better of the two. – puk Nov 08 '11 at 10:01
  • 2
    There is now TortoiseGit. Perhaps you'd like to edit your answer. – Phonon Jan 25 '12 at 18:06
  • 4
    There is technically no "central" git repo. All repos are equal. You can push or pull from any repo to another, assuming you have permission on the appropriate end. Of course, you can easily set up a repo to ACT as a centralised repo, but in reality it's no different to the others. – naught101 Mar 13 '12 at 10:39
  • 2
    It's a long time since this answer was posted, so I thought it would be worth highlighting [Github for Windows](http://windows.github.com/) – ED-209 Jan 02 '13 at 14:32
  • 1
    Check out SourceTree (now available for windows too) - it's free and in my opinion it is the best! [The SourceTree site](http://sourcetreeapp.com/) – ofirbt May 01 '13 at 11:59
  • Hey, it's 2018. 10 years since the answer. Wait, what... what is SVN ?? – Anubis Apr 09 '18 at 14:06
114

I have never understand this concept of "git not being good on Windows"; I develop exclusively under Windows and I have never had any problems with git.

I would definitely recommend git over subversion; its simply so much more versatile and allows "offline development" in a way subversion never really could. Its available on almost every platform imaginable and has more features than you'll probably ever use.

Dark Shikari
  • 7,941
  • 4
  • 26
  • 38
  • 9
    I, on the other hand, had quite some problems with git on windows, it did really strange things to my repo. And I was using the most recent version in cygwin (it was something like a month ago). – Roman Plášil Jun 13 '09 at 08:32
  • 7
    @Roman: well, the Cygwin port is hardly the same thing as the native win32 port. I expect the Cygwin port is much less well-tested... – SamB Mar 30 '10 at 22:32
  • 50
    "more features than you'll probably ever use" is a red flag in my book – B T Jun 05 '11 at 01:36
  • 27
    @ B T "red flag" I disagree. I often find myself wishing there was a way to do something and after a little bit of searching I find out there are a few commands I didn't know about that do just that. I use GIT on my windows machine as well and have yet to have any major problems. – testing123 Aug 04 '11 at 16:17
  • @testing123 but then they are not features "you'll probably [n]ever use" because you actually ended up using them. – mulllhausen Jun 06 '12 at 06:29
  • I'm not sure why you comment is directed at me :). I agree, and that was the point of my comment. I think you meant @BT. – testing123 Jun 07 '12 at 14:23
76

Here is a copy of an answer I made of some duplicate question since then deleted about Git vs. SVN (September 2009).

Better? Aside from the usual link WhyGitIsBetterThanX, they are different:

one is a Central VCS based on cheap copy for branches and tags the other (Git) is a distributed VCS based on a graph of revisions. See also Core concepts of VCS.

That first part generated some mis-informed comments pretending that the fundamental purpose of the two programs (SVN and Git) is the same, but that they have been implemented quite differently.
To clarify the fundamental difference between SVN and Git, let me rephrase:

  • SVN is the third implementation of a revision control: RCS, then CVS and finally SVN manage directories of versioned data. SVN offers VCS features (labeling and merging), but its tag is just a directory copy (like a branch, except you are not "supposed" to touch anything in a tag directory), and its merge is still complicated, currently based on meta-data added to remember what has already been merged.

  • Git is a file content management (a tool made to merge files), evolved into a true Version Control System, based on a DAG (Directed Acyclic Graph) of commits, where branches are part of the history of datas (and not a data itself), and where tags are a true meta-data.

To say they are not "fundamentally" different because you can achieve the same thing, resolve the same problem, is... plain false on so many levels.

  • if you have many complex merges, doing them with SVN will be longer and more error prone. if you have to create many branches, you will need to manage them and merge them, again much more easily with Git than with SVN, especially if a high number of files are involved (the speed then becomes important)
  • if you have partial merges for a work in progress, you will take advantage of the Git staging area (index) to commit only what you need, stash the rest, and move on on another branch.
  • if you need offline development... well with Git you are always "online", with your own local repository, whatever the workflow you want to follow with other repositories.

Still the comments on that old (deleted) answer insisted:

VonC: You are confusing fundamental difference in implementation (the differences are very fundamental, we both clearly agree on this) with difference in purpose.
They are both tools used for the same purpose: this is why many teams who've formerly used SVN have quite successfully been able to dump it in favor of Git.
If they didn't solve the same problem, this substitutability wouldn't exist.

, to which I replied:

"substitutability"... interesting term (used in computer programming).
Off course, Git is hardly a subtype of SVN.

You may achieve the same technical features (tag, branch, merge) with both, but Git does not get in your way and allow you to focus on the content of the files, without thinking about the tool itself.

You certainly cannot (always) just replace SVN by Git "without altering any of the desirable properties of that program (correctness, task performed, ...)" (which is a reference to the aforementioned substitutability definition):

  • One is an extended revision tool, the other a true version control system.
  • One is suited small to medium monolithic project with simple merge workflow and (not too much) parallel versions. SVN is enough for that purpose, and you may not need all the Git features.
  • The other allows for medium to large projects based on multiple components (one repo per component), with large number of files to merges between multiple branches in a complex merge workflow, parallel versions in branches, retrofit merges, and so on. You could do it with SVN, but you are much better off with Git.
    SVN simply can not manage any project of any size with any merge workflow. Git can.

Again, their nature is fundamentally different (which then leads to different implementation but that is not the point).
One see revision control as directories and files, the other only see the content of the file (so much so that empty directories won't even register in Git!).

The general end-goal might be the same, but you cannot use them in the same way, nor can you solve the same class of problem (in scope or complexity).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 10
    I don't disagree with you that git and svn are fundamentally different, but I do disagree on many of your points. svn may have been written to replace cvs, but they're in no way related otherwise, while cvs started as scripts on top of RCS so there's a direct relation. Still, the person you are quoting is entirely right, they both fundamentally manage revisions of files, the implementation and the process in which that happens (or how it does it) are implementation details. It's like the difference between CRC and SHA1, fundamentally very different but they do the same thing. – Erik Funkenbusch Jul 04 '13 at 01:58
38

2 key advantages of SVN that are rarely cited:

  1. Large file support. In addition to code, I use SVN to manage my home directory. SVN is the only VCS (distributed or not) that doesn't choke on my TrueCrypt files (please correct me if there's another VCS that handles 500MB+ files effectively). This is because diff comparisons are streamed (this is a very essential point). Rsync is unacceptable because it's not 2-way.

  2. Partial repository (subdir) checkout/checkin. Mercurial and bzr don't support this, and git's support is limited. This is bad in a team environment, but invaluable if I want to check something out on another computer from my home dir.

Just my experiences.

user154489
  • 381
  • 3
  • 2
  • 7
    "please correct me if there's another VCS that handles 500MB+ files effectively" - Perforce of course! – James Creasy Jun 22 '10 at 23:49
  • 8
    Perforce = non free. Also, Perforce is not available for all platforms. – WhyNotHugo Sep 17 '10 at 14:48
  • 4
    Why not put the SVN repo INSIDE the truecrypt containers? You could also tunnel that though ssh, and configure the server to store that particular repo inside another truecrypt file. This has the added advantage that you can make partial checkouts of that repo. – WhyNotHugo Sep 17 '10 at 14:49
  • 1
    @Hugo as far as I know, Perforce client is available for Windows, Unix, Linux variants, Mac, Amiga, BeOS, Cygwin, HPUX, IBM AS/400, OS/2, DEC VMS and Novell File Server. Is there some relevant platform missing from the list? – eis Feb 14 '12 at 10:20
  • 1
    Yes, OpenBSD (and I knew this from experience, didn't need to google this). I guess it won't work on maemo either, though I might be wrong (and yes, I use git on maemo). – WhyNotHugo Feb 29 '12 at 04:57
  • I wouldn't snapshot encrypted volumes. – earthmeLon Jul 11 '13 at 04:37
  • "Large file support." 14 years later, does git have large file support similar to SVN? – Alex May 16 '23 at 22:15
25

After doing more research, and reviewing this link: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Some extracts below):

  • It's incredibly fast. No other SCM that I have used has been able to keep up with it, and I've used a lot, including Subversion, Perforce, darcs, BitKeeper, ClearCase and CVS.
  • It's fully distributed. The repository owner can't dictate how I work. I can create branches and commit changes while disconnected on my laptop, then later synchronize that with any number of other repositories.
  • Synchronization can occur over many media. An SSH channel, over HTTP via WebDAV, by FTP, or by sending emails holding patches to be applied by the recipient of the message. A central repository isn't necessary, but can be used.
  • Branches are even cheaper than they are in Subversion. Creating a branch is as simple as writing a 41 byte file to disk. Deleting a branch is as simple as deleting that file.
  • Unlike Subversion branches carry along their complete history. without having to perform a strange copy and walk through the copy. When using Subversion I always found it awkward to look at the history of a file on branch that occurred before the branch was created. from #git: spearce: I don't understand one thing about SVN in the page. I made a branch i SVN and browsing the history showed the whole history a file in the branch
  • Branch merging is simpler and more automatic in Git. In Subversion you need to remember what was the last revision you merged from so you can generate the correct merge command. Git does this automatically, and always does it right. Which means there's less chance of making a mistake when merging two branches together.
  • Branch merges are recorded as part of the proper history of the repository. If I merge two branches together, or if I merge a branch back into the trunk it came from, that merge operation is recorded as part of the repostory history as having been performed by me, and when. It's hard to dispute who performed the merge when it's right there in the log.
  • Creating a repository is a trivial operation: mkdir foo; cd foo; git init That's it. Which means I create a Git repository for everything these days. I tend to use one repository per class. Most of those repositories are under 1 MB in disk as they only store lecture notes, homework assignments, and my LaTeX answers.
  • The repository's internal file formats are incredible simple. This means repair is very easy to do, but even better because it's so simple its very hard to get corrupted. I don't think anyone has ever had a Git repository get corrupted. I've seen Subversion with fsfs corrupt itself. And I've seen Berkley DB corrupt itself too many times to trust my code to the bdb backend of Subversion.
  • Git's file format is very good at compressing data, despite it's a very simple format. The Mozilla project's CVS repository is about 3 GB; it's about 12 GB in Subversion's fsfs format. In Git it's around 300 MB.

After reading all this, I'm convinced that Git is the way to go (although a little bit of learning curve exists). I have used Git and SVN on Windows platforms as well.

I'd love to hear what others have to say after reading the above?

Jason Braucht
  • 2,358
  • 19
  • 31
Waqar
  • 315
  • 4
  • 2
  • 15
    Git is incredibly fast on some operations, mainly because the operation only affects your local repository. A Git checkin, for example, should not _justly_ be compared to a SVN checkin, because a SVN checkin is also a push of the change to a staging repository for the rest of your team. That _requires_ a network hit, and comparing Git's no network commit to a network transfer smacks of inappropriate comparison. If you commit, and then lose the hard drive, with Git you lost your change. That's fine if that is what you grow to expect, but it's not expected in non-distributed SCMs. – Edwin Buck Mar 29 '12 at 21:59
  • 1
    @EdwinBuck Not taking what Waqar did into account, in tests even with network time taken into account git tends to be faster: http://git-scm.com/about/small-and-fast – Sqeaky Jun 07 '13 at 18:33
  • Your "Creating a repository is a trivial operation" point is *extremly* important, especially on Windows: compared to SVN, it's far easier to quickly simulate a bunch of interconnected distributed repos, all conected to a central (--bare) repo with Git than it is to do the analogous with SVN (install Windows SVN server application, etc). Also (bizarely) I find Git to be more consistent across OSs: the command line is very well designed and thus sufficient most of the time (and virtually identical between OSs) vs various SVN native client/server apps... – Shivan Dragon Oct 10 '14 at 11:35
  • 1
    The wiki article you refer to is full of mistakes. Therefore, your answer is wrong. Downvoted. There is a talk page on the wiki that refers to http://www.svnvsgit.com/ telling why the comparison is wrong. – bahrep Dec 27 '15 at 13:56
  • Incredibly fast? I've moved the ciforth project from a local cvs to github. This is a simple project but has one large main source file of 10,000 lines. If I try to use blame on this file github falls in a time out. Mostly if one is not content with saying fast, and insist in using such a qualifier it is not a balanced opinion, making me suspicious about all you say. Groetjes Albert – Albert van der Horst Jun 29 '17 at 10:40
  • Creating a repository is a trivial operation for rcs, just mkdir RCS and even that is not necessary. I make "a new repository" all the time for lectures, solutions to euler problems and every simple program idea that pops up in my mind to tryout. So you can get by with much less, if you want simple things. The last bug was removed more than 20 years ago. Groetjes Albert – Albert van der Horst Jun 29 '17 at 10:56
12

I would set up a Subversion repository. By doing it this way, individual developers can choose whether to use Subversion clients or Git clients (with git-svn). Using git-svn doesn't give you all the benefits of a full Git solution, but it does give individual developers a great deal of control over their own workflow.

I believe it will be a relatively short time before Git works just as well on Windows as it does on Unix and Mac OS X (since you asked).

Subversion has excellent tools for Windows, such as TortoiseSVN for Explorer integration and AnkhSVN for Visual Studio integration.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
11

The funny thing is: I host projects in Subversion Repos, but access them via the Git Clone command.

Please read Develop with Git on a Google Code Project

Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.

Using Git on a Svn Repository gives me benefits:

  1. I can work distributed on several machines, commiting and pulling from and to them
  2. I have a central backup/public svn repository for others to check out
  3. And they are free to use Git for their own
Andre Bossard
  • 6,191
  • 34
  • 52
9

Not really answering your question but if you want the benefits of Distributed Revision Control - it sounds like you do - and you're using Windows I think you'd be better off using Mercurial rather that Git as Mercurial has much better Windows support. Mercurial does have a Mac port too.

David Webb
  • 190,537
  • 57
  • 313
  • 299
9

If your team is already familiar with version and source control softwares like cvs or svn, then, for a simple and small project (such as you claim it is), I would recommend you stick to SVN. I am really comfortable with svn, but for the current e-commerce project I am doing on django, I decided to work on git (I am using git in svn-mode, that is, with a centralised repo that I push to and pull from in order to collaborate with at least one other developer). The other developer is comfortable with SVN, and while others' experiences may differ, both of us are having a really bad time embracing git for this small project. (We are both hardcore Linux users, if it matters at all.)

Your mileage may vary, of course.

ayaz
  • 10,406
  • 6
  • 33
  • 48
8

The main point is, that Git is a distributed VCS and Subversion a centralized one. Distributed VCSs are a little bit more difficult to understand, but have many advantages. If you don't need this advantages, Subversion may the better choice.

Another question is tool-support. Which VCS is better supported by the tools you plan to use?

EDIT: Three years ago I answered this way:

And Git works on Windows at the moment only via Cygwin or MSYS. Subversion supported Windows from the beginning. As the git-solutions for windows may work for you, there may be problems, as the most developers of Git work with Linux and didn't have portability in the mind from the beginning. At the moment I would prefer Subversion for development under Windows. In a few years this may be irrelevant.

Now the world has changed a little bit. Git has a good implementation on windows now. Although I tested not thouroughly on windows (as I no longer use this system), I'm quite confident, that all the major VCS (SVN, Git, Mercurial, Bazaar) have proper Windows-implementation now. This advantage for SVN is gone. The other points (Centralized vs. Distributed and the check for tool support) stay valid.

Mnementh
  • 50,487
  • 48
  • 148
  • 202
  • I am optimistic that the horizon of irrelevancy will be much shorter than a few years. – Greg Hewgill Oct 02 '08 at 09:57
  • Yes, possibly it will only one year. Git has a dynamic development-community. But subversion has too. In a year or two you will have to look at both again to answer this question. – Mnementh Oct 02 '08 at 11:28
  • 1
    It's now a year or two later. How's it lookin? :) – Merlyn Morgan-Graham Nov 09 '11 at 11:40
  • It's more than three years later. :-) I update my answer. – Mnementh Nov 09 '11 at 11:48
  • 3
    Git lacks an extension of the distributed SCM model to the other phases of the software development pipeline. We don't have a good model for distributed release build systems, distributed automated testing, quality control, release control, etc. We are just getting some experimental support for distributed backup, and that's after decades of research. As such Git offers more to the developer and less to the software development process. All Git implementations eventually bless one repo to be the central one, which simplifies the most interesting Git abilities into facsimiles of SVN ones. – Edwin Buck Mar 29 '12 at 22:06
  • @EdwinBuck, I confess that I don't understand. I would say that there can't (meaningfully) be two versions of the same software, so how can it make sense to have two central repositories? Even if you want to test in a distributed fashion, wouldn't it make sense to test the same version of the software? – hibbelig Nov 14 '12 at 21:03
  • 1
    @hibbelig Git doesn't have a central repository, every repository is effectively (due to its distributed design) equal. This means that you either rework your production pipeline to possibly handle all repositories equally, or artificially bless one repository to be of "artificially elevated" status (aka the _central repository_). If you do the former, nobody knows much about building parallel pipelines where a release could come from any developer's desk, if you do the latter, the promise of distributed processing is cheated by centralized convention. – Edwin Buck Nov 14 '12 at 22:14
  • @EdwinBuck I guess you are aware that the problem with distributed repos is that they are /not/ equal :-) (They will have unpushed commits typically.) So the team says that they are only building the version that's on the central repo so that they can be sure that even tomorrow they can recreate the build. If I had been building on my laptop, then tomorrow the team might not be able to recreate the build because I might have had local changes and I'm on vacation. – hibbelig Nov 17 '12 at 23:11
  • @EdwinBuck I guess I'm having a hard time imagining what might be the promise of distributed processing? Is this about speeding up something? Then why can't we have multiple build servers that all pull from the central repo as their first step? Are you saying that doing this would overload the central repo? I have a hard time imagining this, as I can't imagine that the amount of data to be transferred would become prohibitively large. If the build servers pull from the central repo once a week, how long could that take? – hibbelig Nov 17 '12 at 23:16
  • @hibbelig Exactly what you said. All repos are not equal. You assign one to be "superior", so that defeats the promise of "distributed" by convention instead of by code. Distributed build systems (as I imagine them) might allow a reproducible release build from any laptop. – Edwin Buck Nov 18 '12 at 03:46
7

Definitely svn, since Windows is—at best—a second-class citizen in the world of git (see http://en.wikipedia.org/wiki/Git_(software)#Portability for more details).

UPDATE: Sorry for the broken link, but I've given up trying to get SO to work with URIs that contain parentheses. [link fixed now. -ed]

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
Hank Gay
  • 70,339
  • 36
  • 160
  • 222
  • 1
    FYI: enclose the URL in angle brackets, or replace parentheses with %28 and %29. – PhiLho Oct 02 '08 at 10:35
  • 1
    Will the URL-encoding work for the []() syntax? – Hank Gay Oct 02 '08 at 11:44
  • Instead of "Definitely svn", I'd "IF you use Windows svn", if the user doesn't use it, he doesn't care about it's support. – WhyNotHugo Sep 17 '10 at 15:40
  • @Hugo the question indicates it will be developed using Visual Studio, which is (was?) Windows-only, so they probably do care. – Hank Gay Sep 17 '10 at 18:46
  • 16
    This is incorrect FUD. Git is fantastic on Windows. And SVN is pretty bad everywhere. – Charlie Flowers Feb 06 '11 at 05:21
  • 6
    For all those downvoting me, please go back and look at the developer comments from circa 2008: it's pretty clear that Linus and the gang did not care about supporting Windows. That's fine: I don't really want to do it either, and my software isn't nearly as complex as VCS that expects POSIXish behavior from the filesystem. It seems unfair, though, to characterize my statement as FUD if you look at the context. – Hank Gay Mar 17 '11 at 12:25
  • 2
    Maybe in 2008 git was bad on Windows, but I've been using msysgit since 2009 and it works flawlessly. That includes gitk, the offline desktop equivalent of GitHub. – Dan Dascalescu Jul 01 '11 at 07:49
6

I would opt for SVN since it is more widely spread and better known.

I guess, Git would be better for Linux user.

Burkhard
  • 14,596
  • 22
  • 87
  • 108
  • 1
    This however, is changing quickly. SVN looses market share, while GIT gains: For example: https://www.wikivs.com/wiki/Git_vs_Subversion#Popularity or http://programmers.stackexchange.com/questions/136079/are-there-any-statistics-that-show-the-popularity-of-git-versus-svn#136207 – Zelphir Kaltstahl Oct 30 '15 at 13:06
  • @Zelphir: I wouldn't call 7 years quickly, but yes, GIT gains market shares and is especially way better for merging files. – Burkhard Oct 31 '15 at 19:13
4

Git is not natively supported under Windows, just yet. It is optimized for Posix systems. However running Cygwin or MinGW lets you run Git successful.

Nowadays I prefer Git over SVN, but it takes a while to get over the threshold if you come from CVS, SVN land.

4

I would probably choose Git because I feel it's much more powerful than SVN. There are cheap Code Hosting services available which work just great for me - you don't have to do backups or any maintenance work - GitHub is the most obvious candidate.

That said, I don't know anything regarding the integration of Visual Studio and the different SCM systems. I imagine the integration with SVN to notably better.

Christoph Schiessl
  • 6,818
  • 4
  • 33
  • 45
4

I have used SVN for a long time, but whenever I used Git, I felt that Git is much powerful, lightweight, and although a little bit of learning curve involved but is better than SVN.

What I have noted is that each SVN project, as it grows, becomes a very big size project unless it is exported. Where as, GIT project (along with Git data) is very light weight in size.

In SVN, I've dealt with developers from novice to experts, and the novices and intermediates seem to introduce File conflicts if they copy one folder from another SVN project in order to re-use it. Whereas, I think in Git, you just copy the folder and it works, because Git doesn't introduce .git folders in all its subfolders (as SVN does).

After dealing alot with SVN since long time, I'm finally thinking to move my developers and me to Git, since it is easy to collaborate and merge work, as well as one great advantage is that a local copy's changes can be committed as much desired, and then finally pushed to the branch on server in one go, unlike SVN (where we have to commit the changes from time to time in the repository on server).

Anyone who can help me decide if I should really go with Git?

sth
  • 222,467
  • 53
  • 283
  • 367
Waqar
  • 315
  • 4
  • 2
  • I wouldn't call any developer who copied a SVN controlled folder over into another project to re-use it and didn't expect obvious troubles 'intermediate'. I'd call them novices. Yes, you are right, it is due to the .svn sub-folder that tells SVN to what repository the files belong. If the user deleted this .svn sub-folder, then they could import the folder into the new SVN project. I'm still with SVN myself, but my needs are few. GIT is great for larger projects. – dyasta Jan 27 '12 at 18:44
  • 3
    The latest svn clients don't need a `.svn` folder in each sub-directory. That "fixes" the copying error before it happens. – Edwin Buck Mar 29 '12 at 22:08
4

It comes down to this:

Will your development be linear? If so, you should stick with Subversion.

If on the other hand, your development will not be linear, which means that you will need to create branching for different changes, and then merging such changes back to the main development line (known to Git as the master branch) then Git will do MUCH more for you.

seedg
  • 21,692
  • 10
  • 42
  • 59
3

May I expand on the question and ask if Git work well on MacOS?

Reply to Comments: Thanks for the news, I'd been looking forward to trying it out. I'll install it at home on my Mac.

Robert Gould
  • 68,773
  • 61
  • 187
  • 272
  • 1
    Yes, it works beautifully. I installed it through MacPorts and use it daily. – Greg Hewgill Oct 02 '08 at 09:57
  • It does. It's great on any POSIX-based system (Unix, Linux, Solaris, BSD, etc). It's really just Windows where the problem lies. – Oli Oct 02 '08 at 09:58
  • and the git-gui and gitk probably work the same under OS-X as under Linux and Windows. Contrary to tortoiseSVN, which AFAIK is windows-only? – David Schmitt Oct 02 '08 at 10:28
  • @David Schmitt: well, http://tortoisesvn.tigris.org/ calls it a "Windows Shell Extension for Subversion", so I'd assume so, yes ;-). – SamB Mar 30 '10 at 22:36
  • @Robert: how was your experience with git on OS X? – David Schmitt Apr 01 '10 at 06:21
3

have you tried Bzr?

It's pretty good, connonical (the people who make Ubuntu) made it because they didn't like anything else on the market...

Omar Kooheji
  • 54,530
  • 68
  • 182
  • 238
  • The windows support really does need a bit of work here, though. Not so much that I haven't been quite happily using it for all of my recent programming under Windows (of which I've been doing a fair bit), or anything, but still... – SamB Mar 30 '10 at 22:41
  • It almost 100% of the time with OS, that people "made it [any software] because the didn't like anything else in the market". – WhyNotHugo Sep 17 '10 at 15:42
  • @Hugo With open source, if they liked something else on the market, they would contribute to it instead of making something new. – yingted Aug 13 '11 at 19:14
  • This is not an answer to the question at all – Albert van der Horst Jun 29 '17 at 11:00
  • @AlbertvanderHorst No it's not, the question was answered in the wild west days of SO when no one knew any better, and offered an alternative. Arguable in my haste it looks like I've also misspelled Canonical's name. Shame on me! – Omar Kooheji Jul 12 '17 at 15:13
3

There is an interesting Video on YouTube about this. Its from Linus Torwalds himself: Goolge Tech Talk: Linus Torvalds on git

Roman Ganz
  • 1,615
  • 1
  • 20
  • 27
2

SVN seems like a good choice under Windows, as pointed by other people.

If some of your developper wants to try GIT, it may always use GIT-SVN where the SVN repository is recreated in a GIT repository. Then he should be able to work locally with GIT and then use SVN to publish its changes to the main repository.

Pierre
  • 2,858
  • 22
  • 21
1

You have to go with a DVCS, it is like a quantum leap in source management. Personally I use Monotone and its sped up development time no end. We are using it for Windows, Linux and Mac and it has been very stable. I even have buildbot doing nightly builds of the project on each of the platforms.

DVCS while being distributed usually means you will create a central server just for people to push changes to and from.

Phil Hannent
  • 12,047
  • 17
  • 71
  • 118