Slashdot Mirror
Practical Reasons To Choose Git Or Subversion?
markmcb writes "I develop Rails applications and recently followed my lemming herd and made the switch to Git after learning some of the practical advantages Git offers over Subversion. As I'm sure there are many die-hard Subversion fans in the Slashdot audience, I'm curious what your key reasons are for sticking with Subversion. If possible, I'd like reasons that apply to 'most of the time' as opposed to arguments based on obscure features that may get used only a few times ever."
You can have my cvsroot when you pry it out of my cold dead fat hands.
Git is an excellent piece of software, but Windows performance is not so great. Git is too UNIX centric to be fast on Windows in the near future.
Other distributed SCMs often are interpreted and just as slow as git (on any platform), so this might not be a concern for me.
Like the bi-line suggests... Unless you are coding in something like vi or emacs, I don't use the command line for my source control. IDE Integration means a lot... most of the items that git 'claims' to be better on is something IDE plugins fix. So the maturity of the plugin and the comfort with using it is a big thing for me. As such, I'm usually using CVS or Subversion.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
They are both of the "distributed" kind.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
Thats all there is it to it, oh mighty one!
You will never have experience until after you needed it.
Seriously. I know it's $800 a user, or something like that, but it's worth every penny. (Yeah, yeah, it's closed source, and ships as a binary, but it _really_ works).
Note that Perforce is free for open source projects.
Comment removed based on user account deletion
Git is not well supported on Windows like Subversion is with turtoiseSVN. There is no good integration in Eclipse or Netbeans. The workflow is more complicated and enterprise tools such as Jira and Confluence do not support it.
These things may improve but right now, Git is not very well suited for use in corporate environments.
DNA is the ultimate spaghetti code.
Because Subversion "Just Works".
I can honestly say that I have no preference of one over the other; having only just heard of them both by the OP.
The most effective use of GIT happens when the team changes its mindset away from the central repository with multiple developers checking into it to a true peer-to-peer development team. I wouldn't switch away from svn until the organization I was with was prepared to "think different" and make that transition. Using GIT like a fancy svn just makes it like a complicated svn, not a better way of doing version control.
Real programmers type cat | cc and get it right the first time.
http://rocknerd.co.uk
Just for reference, it's the Slashdot users who add the tags, not the editors.
Tomato wedge sperm darts that are Republican.
Git wasn't really designed for Windows (where you lack the fork() call and must do everything using CreateProcess()-like API), and therefore the Cygwin port or the state-of-the-art in Git for Windows is horribly slow and inconvenient to use. Documentation is not optimal either; in some places you need to get accustomed with 2 or 3 different terms meaning the same thing, and often you must dig under the hood and learn how the underlying storage works in order to grasp the high-level functions (which doesn't happen in Mercurial's case, for example). For me the #1 blocker is the Windows thing because I'm not an idealist and I need to compromise, I suspect it's even more true in the corporate world.
How odd that I was just watching a talk that Linus gave at Google. Link to the talk
I'm not a fan of SVN. Use it at work, and I find myself missing things CVS does so well, like tagging and branching. Frankly, the features of SVN that are actually better than CVS seem more related to server management than to me, the programmer who needs source control.
I admit, I've never looked at Git at all, I don't know how it compares to CVS or SVN, but I'm not planning on moving my personal projects out of CVS any time soon, sorry.
I'm god, but it's a bit of a drag really...
http://www.youtube.com/watch?v=4XpnKHJAok8
He might not be very objective and his talk obviously only offers one side. Still, might be informative :)
It doesn't really matter whether you use git or subversion as long as you use vi as your text editor.
obviously no deficiencies vs. no obvious deficiencies
I use svn because it makes no sense for me to use a distributed repository for my code. I keep my code on one server, I have my local working copy and I work on that. I use it mainly to see why or when I made a particular change and that's it, so I have no reason to switch to git.
I just don't trust anything that bleeds for five days and doesn't die.
I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.
Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits. If, in the future, you and your team decide you need to change how you do source control, then git, or some other distribute peer-to-peer system, might be the solution. But don't just use it as a drop-in replacement for centralized server development.
I found the Bazaar system to be superior to all other version control systems I have tried, including subversion and GIT.
http://bazaar-vcs.org/
Why? It is fast, it has tools integration and it can be used in much the same way as subversion/CVS. It is much easier to learn and just as powerful as something like GIT.
There might be reasons to use GIT for extreme projects like the Linux kernel, but I believe Bazaar will do just fine for all reasonably sized projects.
SVN is better for Windows users.
Git is better for Git users.
Unless, of course, you're an IE user (ow, stop, the tomatos they burn!) and you get scripting errors on every Slashdot page, thereby making it impossible to tag, metamod, or participate in the new beta index article voting feature.
Well hard decision, I live in both worlds, currently I use svn as central repo and git mainly for versioning local repos. Well both have their advantages and disadvantages. SVNs biggest disadvantage probably is the speed, and the model (which also is its biggest advantage for certain team structures) Gits biggest problems are: Almost total lack of tool integration into existing tools. Rather unstable and not well integrated into Windows. You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally. Git however has the bigger advantage of having a very compact meta format so this disadvantage basically is nullified unless you have a huge codebase with thousands of revisions! I would not despise one or the other. I personally for a mixed team still would choose svn over git as it is currently, mainly due to the unpolished windows integration and lack of visual tool integration (yes git gui is known to me)
I've been using CVS forever, mainly because it was the only real noncommercial option ten years ago. But I'm interested in trying out any versioning system that will work better, because I know I'm abusing CVS with my file storage needs.
I do a fair amount of hobby coding, so any of the systems work well for that. Thousands of tiny text files are easy to merge. The sandboxes are fast and I can set up my repository on another machine on my lan.
However, I also do a fair amount of semi-professional photography. My sandbox may have a couple thousand binary files that range anywhere from 2 MB to 2 GB. The number of versions of a file may typically go as far as 4 or 5, rarely as high as 10. A new version is best handled by simply snapshotting the whole new binary file, like the old VMS filesystem does. My repository on my lan machine has several tens of thousands of these binary files. My sandbox is rarely complete: I only sync certain subfolders now and then, and when I've checked in my changes and need space, I just erase that area of the sandbox. As long as I don't try to (cvs update -d) at the top level, I'm fine.
I know I may be wrong, but if I switched to git or mercurial, as I understand it, every sandbox is/has its own repository with complete history, and these tools are more interested in how to merge changes from repository to repository. This is not what I want, in that the local sandbox+history would easily bloom into the many-gigabyte range and start to crowd my regular working space. I read a bit about their repository 'packing' options but that's not a solution, it's a maintenance feature.
[
Comment removed based on user account deletion
Trac - One reason to use Subversion is the hard bindings you can get with Trac. Nothing enters the repository unless it is tied to a ticket. Ever been to a software process review? This is a must.
With the newer trac versions you can pass the tickets though the review stages and if you just wish to peer-review the code you can do that in Trac without checking out anything at all. Just click on the links in the ticket and you see a diff of the source in the webbrowser.
Tortoise - integration into Windows desktop. You can immediately tell by looking at the folder icons what needs to be checked in. Right click on a folder and select commit or update etc... For some reason this tools is so much better than anything on Linux...
The truth is that despite the amount of invective on the subject, the choice of source control tools is not going to have any measurable impact on your project. Hell, most projects could easily run without a problem on a non-buggy version of MS-SourceSafe (if such an animal existed).
The biggest cost you're going to have with your source control package is the initial setup. The biggest benefit you're going to get from your source control package is going to be minimizing that cost. Choose any of the modern source control packages and just get on with what you're being paid to do: write code.
Why doesn't Slashdot ever get slashdotted?
*applause*
http://rocknerd.co.uk
Mercurial is something of a halfway point between the ease of Subversion and the power of Git, with the added advantage that it works well on Windows and has both GUI wrappers and IDE integration.
I use Git over Hg primarily because I *do* use the command line for everything (and Git's CLI is nothing short of excellent), but Subversion is just painful with any amount of wrapping.
Many of the things that Git touts as huge improvements over svn really don't apply to any collaborative work I have ever done. So what, I can show people my little version of the repo with out committing it? I can just send the source files to them out of my svn checkout. So what, I can stash stuff and come back to it later? I can branch and merge in svn. I can leave comments, like every good programmer should, so that I will know what was done on the branch, and the current status of the project at a glance. So what, I can check stuff out of and commit the source on my local system without network connections? I can make multiple copies of my version of the source code that I checked out of the svn repository. In either case, if you don't make sure you have the latest copy of the code, you are gonna have fun trying to merge it later. So what, Git will allow me to make patches so that I can show the changes to my coworkers? I could just as easily send them a diff of my copy and the svn repo.
There is nothing wrong with git. I just don't see a clear advantage to it. In every argumentative paper I have seen about git vs svn, they always tout the above "advantages" of git. These items don't translate to actual advantages during project work, in my experience. If anything, the multiple local repositories all over the place, would seem to me, to cause more wasted time trying to merge in changes to the central repository, because of the local git repo's having a tendency to allow themselves to get so out of date.
The main reason I use svn still, is because I learned it first, it does not have any disadvantages, for me, when I compare it to get, and it is well supported, and has a large developer base.
Comment removed based on user account deletion
Consider also:
Mercurial : http://www.selenic.com/mercurial/wiki/
darcs : http://darcs.net/
They all have their advantages and disadvantages. Yes, git is exciting, trendy, and (gasp!) Linus uses it, but distributed version control systems weren't born with Git and so there are other options to consider.
I've used CVS, SVN, Bitkeeper, darcs, and mercurial on Linux and Windows machines. These days, I stick with SVN for very large projects and mercurial for small and medium projects as well as all my personal stuff that isn't shared with other developers.
I'm in the same camp. I have to manage version control with some less than sophisticated Windows-based web guys, and TortiseSVN works well for that purpose.
Personally, I come from a CVS on UNIX background so the smooth repository transition and similar commands and usage style were handy. All I needed out of a "better CVS" was the ability to version file name changes. If you aren't coming from CVS, I think SVN loses much of its charm.
I'd be all over Git if I thought distributed repositories would be helpful for my projects, and I'm thinking of tooling around a little with it on the side just to keep up on all this new fangled stuff you kids are using these days.
Rails, not so much. It looks nice, but it tickles my "get off my lawn" reflex.
If you say, "now I'll be modded down because of X", I'll happily oblige.
Seriously. I've been stuck using that turkey for several years now. Want to get all the changes people have checked in today? Hit the sync button and head out to lunch, because it's going to be an hour. Want to check in a decent sized (hundred files) changelist? Hit the checkin button and go for a cup of coffee. Want to check in a large (ten thousand files) changelist? Hit the checkin button and go home; if you're lucky, the checkin will be done by the time you come back tomorrow.
Eclipse plugin, ant tasks for builds and TortoiseSVN. Most developers I work with don't use command line svn.
Precisely. I don't use Subversion for managing code anymore because for merging the distributed version control systems are much much better. However, Subversion is an excellent versioning file system, and that's what most people actually want. It handles large files well (try checking a 500M file into git, mercurial or bazaar sometime), and it can even be used as a WebDAV share for completely braindead use by normal end users. End users see the repository as a Network drive, but I can go back and get old revisions easily.
Now that Subversion has more advanced merging abilities it might even be suitable for shops that like Subversions centralized nature but still need to merge on a regular basis.
Besides, mercurial, git, and bazaar all interface well with Subversion. I frequently use bzr as a front end for subversion repositories if I know I am going to be doing any merging.
The DragonFly project is planning on moving out of CVS and has been looking at various repositories. We aren't actually interested in Subversion per-say, not any more, but some of our developers have used GIT and a few are advocating for mercurial as well. We need to come to a decision by mid-november.
I haven't used Mercurial yet myself. I have used GIT. It took about a week to get used to it but once I understood the contextual labels things became a lot more obvious. We will maintain our central repository either by having it pull from the individual developer's repositories or by having the developers push into it. I'm still not quite sure what the best methodology is. It has to be automated no matter what.
If someone is using GIT in a similar manner I would like to hear your story.
I would also like to solicit opinions from people on GIT vs Mercurial.
-Matt
Funny, but I've never got the IDE plugin for *any* version control system working well. Since I always have at least one command window open, typing "git commit -a" is faster and easier than locating the corresponding menu, clicking on it, and praying that it will do exactly what I want.
Disclaimer: Of course, this doesn't mean I don't use the many other functions that work better on an IDE than in a text command. I can use vi occasionally for a quick edit, but development of a large code base is much easier and quicker on a good IDE. It's just that version control is quicker on the command line.
Only wimps use source control. Real men just upload their important stuff on ftp, and let the rest of the world mirror it.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I'm sure that's just by accident. I suggest you explain the site maintainer, preferably in all caps, how poorly their site is programmed.
Most of the time support and ease of handling comes before smallish differences in features - some of which are still debatable, like "floating"/"stashing" changes. Subversion's support in Windows (tortoise, ankh, netbeans, etc.) and in widely used IDEs (netbeans and vs in the lead) is a _very_ strong point.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
But don't just use it as a drop-in replacement for centralized server development.
I disagree. You can take advantage of git's other positive aspects even if you manage a central repository: Common operations are speedy, local branching, and easy merges are all benefits you get by using git regardless of whether you take advantage of the distributed nature of git or not.
I won't go so far as to say that all other SCM is total crap, but having recently switched my code repositories to centralized git repositories, I certainly wouldn't go back or put a new project in anything else. It was so easy converting my previous repositories to git (preserving history) that I think many people can and should consider git as a "drop-in replacement" for other SCM.
The only reason I can think of to not go with git is (like the OP pointed out) the lack of nice UI tools (and premature Windows support). I can totally understand how this may be a show-stopper for many groups and projects, and that's fine. But to those groups or individuals not on Windows who aren't afraid of a few easy command-line programs, do yourself a favor and switch to git. Really, it's that much nicer.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
We stick with svn because it works for what we do, and it works well. There's only two of us who are developers anyway, so the benefits of git aren't of any importance. There really wouldn't be any benefit on changing - svn does what it says on the tin, and what it says on the tin works very well for us.
Oolite: Elite-like game. For Mac, Linux and Windows
My own opinion is that version control systems are so mind-bogglingly difficult to use, I prefer to use a versioning file system and code packaged (occasionally) in tarballs. CVS/SVN are too clunky IMHO, and Git is only really usable if you happen to have a cloned version of Linus's brain nearby.
Thinking about it, a versioning file system has all the features I need (source code branching and merging? just use cp) but that's my own opinion. If you're desperate to use a VCS, are using *nix (Linux, OS X, Solaris, etc) and feel brave, give git a try - it's speedy and flexible (but still mind-boggling). For speed on Windows, Subversion's a better option.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
I'm using subversion today and I plan to switch to git soon. I can think of two main reasons to use svn:
1. git doesn't work well on Windows;
2. svn plays well with a lot of IDEs and similar tools.
Neither of those points matter to me, hence the upcoming switch.
Reasons to NOT choose a DVC over another DVC:
Baazar: Is really slow for big projects.
Git: Very, very, very fast, but it sucks on Windows.
Mercurial: Slower than Git.
Now, use Subversion if you need a restrictive control system (permissions, etc.)
With these new features, they eventually get legacy browsers working.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Why would you tag in SVN? Since I started using SVN, I stopped tagging code. Instead I just use the repository version.
How about HG (mercurial)? It offers the best of both worlds supporting excellent windows integration (TortoiseHg, Eclipse plugins, etc) and having a large subset of similar features compared to git.
Trying to install linux on my microwave, but keep getting a kernel panic...
I'd like reasons that apply to 'most of the time' as opposed to arguments based on obscure features that may get used only a few times ever.
You must be new here.
And soon! The next installment of disagreemail is just days away!
*wretch*
FGD 135
Comment removed based on user account deletion
My biggest reason for switching to Git was that it makes backing up repositories vastly simpler.
In subversion I had to set up a repository with svnsync, and that repository couldn't be used interchangably with the original. And I would constantly have to go in and figure out how to unlock the destination repo. Lots of problems.
With git, I just clone the original repository and do a pull once in a while. And if I want, I can easily switch my clients to use the alternate repository (e.g., if a server goes offline).
I've been using msysgit for months and have had no issues with it. I don't quite understand the argument that 'git is terrible on windows'.
Duct tape, XML, democracy: Not doing the job? Use more.
Trying to make git within that model is just adding complexity without getting the benefits.
Bless you for saying so.
Last year I nearly had to murder somebody because he was pushing git for 6 guys in the same office producing a web site that released weekly. I agreed that git was cool, and were I doing a distributed project, especially an open-source one, I'd love to use it. But I just couldn't see the value for a bunch of guys who worked off of trunk, were on the same LAN, had exactly one version in production, and checked in between a few times a day and a couple times a week.
If people feel there is a value for a team in that situation, let me know, as I'd love to hear about it.
I've had a couple of small teams over the last several years, and we don't have a lot of time to mess around with managing the version control system. trac was an attractive (and free) project management tool with nearly 100% painless svn integration - living with both for over 2 years now, the only thing the system asks of me is to copy off the .tar'ed backups once in awhile, and I suppose I could automate that too...
Never looked seriously at git due to team size (ranges from 3-6 depending on how you count...) and the utter painlessness of a trac-svn install. We did expend a few days effort to get trac-svn to run native under OS-X, but after that when it was time to set up a new system, we just got somebody's 10 year old PC and installed Debian and trac-svn on it, took less than a day and has worked like a champ ever since.
The svn access tools under Linux/OS-X/Windows are also pretty slick and easy.
...opposed to arguments based on obscure features that may get used only a few times ever
you must be new here.
The first feature of any source control system that matters is "reliable". A source control shall not loose source code. No exceptions.
The biggest part of "reliable" comes from being "idiot proof". There should be nothing that any of my fresh-out new hires can do that can cause loss of code. And, teaching a new hire how to make a working branch and populate a project should only take a few minutes.
Central backup is also a big part of "reliabile". If there is only ONE disk/filesystem that has to be backed up, we can mirror it and journal it, and back it up every night, with no problem at all.
Code maturity is the third big component of "reliable". A source-control system that has been around for less than a decade might still have some important bugs.
All those nifty features are, by comparison, not really very important.
SVN gives me cross platform client support, and there hasn't been anything that I wanted to do that I couldn't. So SVN for me. Does GIT support WebDAV?
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
Subversion usability leaves a lot to be desired (although the book is really nice). For example, cd into a working copy that you've never seen before and try to determine its exact repository URL. Or, try making a branch without typing in the entire repository URL (assuming you even know it). Ugh.
Subversion and Visual Source Safe are the only two version control systems that I've ever had repository corruption problems with, so I'm biased against these.
For me, these days it's RCS or git for personal use, and git or CVS for group use, depending on the specific interaction pattern.
"Not an actor, but he plays one on TV."
A while ago, I read this great post from thoughtbot on the issue. I tend to agree with them. Subversion makes sense for client projects and other propriety projects you need more control over. Git is great for OS projects. http://giantrobots.thoughtbot.com/2008/4/15/moving-to-github
We got around the central server by using wandisco's multisite product. They have a high availability solution as well but we wanted to have local read/write speeds at all our locations.
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
I don't use Windows for development, but I DO need my IDEs.
Git fails because of the lack of integration. Until it has that, it does not fit my needs. What's more, it fails to start with because they didn't consider that in the first place. A "simple text editor" dev environment stopped being useful or productive back in the 90s.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
False premise. Mercurial, for now, seems a better alternative. It has wonderful integration with windows (TortoiseHg) as well as eclipse. It is very fast and featurewise equivalent with git.
A distributed vcs can do *everything* a centralized one like svn does, but does it better, does more. You'll find yourself doing things with it that are *possible* with svn, but so painful that you would never actually contemplate doing them.
I personally cannot think of a reason to start using svn at this point. If you are currently using it, stick with it if it works for you.
For any new project (and some old ones) a distributed source control tool is going to be just plain better. The majority of the gains come from the ease with which you can branch/merge/otherwise alter your local copy of a repo.
When I use svn, the code has to be right before I check it into the central repo, which means I don't keep any version history locally. This sucks if I make any mistakes.
With a dvcs (I use mercurial personally, but git is fine), I keep a much more constant history, try out crazy ideas with a branch, merge three or four branches to get all of the new features into one place, almost without thinking about it. All of this happens locally - no need to push it to a central repo.
The most common complaint about dvcs is that they aren't centralized. This is just a question of workflow - a dvcs allows you to impose your workflow on your codebase rather, than your vcs imposing it's workflow on you.
Your project needs a central repo? Fine - just designate one. Clone it, branch, merge, do a little dance, and push your changes back. Need more control over your project? Don't allow pushes - only pull once someone's local repository passes your unit test suite.
Because it is so much easier to get started and keep up with, I find myself versioning almost all of my work. It takes very little effort, and has saved my bacon a couple of times. I'd never have tried anything on this scale with svn, for fear of having to kill myself.
-V-
Who can decide a priori? Nobody.
-Sartre
Yea, I know GIT is distributed, but it's easier to manage subversion with the one main server.
Everyone that worked with ruby probably heard of github by now, which actually defeats the purpose of distributed versioning, yet I think it's still popular not because git is so fast, but because svn is that slow.
Mercurial has the distributed features svn lacks, and the actual usable interface which git lacks.
This is all you need to know.
Stick Men
I know a lot of people don't like CVS and I can understand why in many cases. Most of the problems I had with CVS were solved by using CVSNT instead. Mind you I work in a relatively small shop with just a few developers, but CVSNT does make CVS a lot more like SVN as far as basic features. It still depends on talking to the server for practically everything which is a problem in an environment that isn't always connected to the server, but for me if I'm not connected to the servers network, development becomes a pain for other reasons so its not that big of a problem.
I've discussed the differences between SVN and CVSNT with many diehard SVN supporters and I've run into to major problems. First off, they seem to be fanboys in a lot of cases, which results in me going into fanboy mode as well and most of the time makes the whole discussion absolutely pointless. Second is that most people can't accept that CVSNT has dealt with a lot of the problems of CVS and continue to think of CVSNT as CVS.
As always, your milage may vary, and if you are in an environment where your developers aren't always connected, subversion and git are both probably better choices reguardless of feature sets when compared to CVS/CVSNT. In our case, its rather nice to be able to use CVS to talk to our version control servers if they don't have CVSNT (or svn or otherwise) installed, and the various tools that will work with the cvs binaries will continue to work for the most part with the cvsnt binaries, the only one I've had problems with is cvsmonitor, which I love, but don't love enough to patch it to work with cvsnt properly so you have to do some hacks while setting up a new project so that it thinks you're using regular CVS long enough to get started, then you can switch to back to using the cvsnt tools. This is mostly because we use SSL connections (sserver) to talk to our cvsnt server which cvsmonitor does not like at all during the setup phase of new repositories.
Just my two cents, which probably wasted more of your time then this post was worth.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Subversion is built around the notion that you meant to do that. Someone checked in their entire hard drive to the repository by mistake? they meant to do that! Getting it out now involves rebuilding the whole frikin repository.
It also does not deal well with large projects. I tried checking in about 25,000 stored procedures. It became glacially slow.
There are also some interesting bug that occur if two people add the same file from two different machines in the same tree. (Working from the same tarball, for example.) Both can add, but only one can check in. The one who checks in second gets to hack on the metadata before he can check in again.
Subversion is much better than CVS. Git is much better than Subversion.
I would repeat a quote from Linus Torvalds about Subversion, but it would trigger to many work-place profanity filters.
"Trademarks are the heraldry of the new feudalism."
When CVS ruled the world, I found it complicated and had certain problems with it: but aside from that loved it and version control in general.
When SVN became available, it's like someone read my mind. It kept everything I loved about CVS, and fixed everything I hated. Coupled with the awesomeness of TortoiseSVN for my windows workstations, I simply have no complaints with SVN. Anything I want to do can be done simply and I've never hit a roadblock.
Keep in mind I use Linux CLI and Windows GUI. If you depend on Linux or Macintosh GUI, then you probably lack a tool like tortoise. If you are on Mac you probably love Textmate's GIT integration.
Finally, my use case is different. I entertain one or at most two experimental "branches" of code at a time, and with no need of collaboration so they are really just local working copies. I am able to commit them to full fledged branches and even merge via SVN with ease but rarely need to. Other developers on my team (there are only 3 of us) tend to keep their experimental code in working copies as well.
I would imagine GIT shines when you don't want a central repo, you spend inordinate time coding with no net connection, you don't use windows, you do use textmate, and/or you have 100 developers distributed around the globe each entertaining 1,000 branches at a time with every branch needing peer review in triplicate before anything touches the trunk. If that paragraph describes you then huzzah, I wish you and git well. But if you are a small team on one or many small projects and need to function reasonably well in Windows environments, git isn't the right fit.
People willing to trade their freedom of expression for temporary entertainment deserve neither and will lose both.
Well, you asked for opinions, and here are mine:
Go with either bazaar or mercurial. There's not really any reason to consider subversion any more, and frankly I find git too weird to be usable.
Bazaar and mercurial are very similar and both have command sets that seem based on subversion. Bazaar has two nice features that Mercurial lacks: It can work with a central repository, very similar to subversion, and it has launchpad.net, which is a very nice project site. If you don't need either of those features I'd go with Mercurial though, since it's quite a bit faster.
Hey, just be glad it's tech related and somewhat interesting. If I see another slashvertisement, "OMG! copyrights are teh evil!1" or "Big brother is coming!1" story, I'm going to puke.
Git, Bazaar, Mercurial, Darcs and a few other distributed systems are the only ones I've entertained since I lost interest in RCS/CVS years ago. No one in their right mind should be even thinking about so-called tools like SVN these days.
Even just to keep my simple documents like lesson plans and tutorials up-to-date across a few machines and platforms I don't control (with pen drives/emails in-between), I need to use rsync-like tools that can cope with more than a single central repository, and sync in both directions. The days of big central mainframes which hold the One True Source Code Repo are long gone.
So far, my thoughts are this:
Bazaar( aka bzr, aka bazaar-ng until recently ): very nice, but a little flakey now and then.
Git: seriously fast, powerful, but too complex for any project with lay-contributors and too easy to hose your work with
Mercurial and Darcs: not much experience with them, but at least Mercurial's TortoiseHg option for windows seems ready to go, which is a huge win if you care about a cross-platform solution.
What size is your project? For small projects with one to three people who all work in the same place yu can use RCS. It is serverless and works inside the file system. For many years I simply NFS mounted the RCS directories onto the development machine. There is almost zero setup and very little learning curve.
CVS was a server centric RCS. If you don't need a server because you are the only developer on the project RCS is everything you need
I also use RCS for all those small 8.conf file in /etc. just do a "mkdir /etc/RCS" and you are setup and running. It's that easy.
So as a cmd-line user who only uses centralized repositories (with only a couple of other developers), what kind of benefits would git provide over subversion?
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
The main reason why I stick with Subversion is that git can't do incremental checkouts, which means that you always have to clone the complete repository. While this isn't that bad for text files, since git can compress them down good enough that the end result isn't much bigger then just the current version, it is pretty bad for binary files, since there isn't much compression that can be done andthings quickly get really huge. Also with Git you don't have the option to just download a single directory, so having a media repository for a game where people only checkout what they really need doesn't work. Both of this combined basically makes Git unusable for managing binary files.
On the plus side Git is very good for in-place repositories, i.e. when you want to manage a directory with Git you just type 'git init' and are done, with SVN you have to copy stuff around, check it in and its all very cumbersome to add version tracking to a directory after you already created it. This feature of Git makes it a great RCS replacement for config files and other stuff.
Subversion allows exclusive edit privileges.
I am envious of you who working in this mystical land of mergeable data.
A "simple text editor" dev environment stopped being useful or productive back in the 90s.
I'm a minority race. Save your vitriol for white people.
I have been using SVN for couple of years on my current project (and I don't know how many years on other projects).
I started running GIT on the side in order to such changes from the open source components so I could make the open source changes available outside the proprietary project I get paid to work.
So I have SVN and GIT running side by side on a Windows system for work. I have a linux system that is used for the open source development outside of work.
Conclusion: SVN is way, way, way slower. On windows. Git is way, way, way faster than SVN, almost instantaneous. On Windows.
But I can't get the company to move to GIT. Why?
Maven integration. Maven doesn't talk to GIT.
JIRA integration. I don't think JIRA talks to GIT (but I haven't looked at it as much).
Eclipse Integration. Now this one I don't understand. But it matters to other people on the team.
GIT Downside: It took me a weekend to learn it. Stupid stuff setting up a repository on repo.or.cz, getting Putty to provide keys and crap. Nothing I can't document and make easy for someone else, but a pain in any event.
SVN Downside: It really is slow. Tortoise is a wonderful thing for Windows Integration. However, it remains true that one has to constantly clean one's trees, and we have spreadsheets in our project (don't ask! Please!) and Excel locks horns with SVN if you are not careful to kill Excel first, etc. etc.
I would like to use GIT. It is wonderful. But the issues above are killers at work.
On my own and for projects I manage, I will use GIT with a SVN publishing face for consumers.
If that ever happens.
People should use the tool that best supports their productivity. If it is Git, then fine. If Subversion, then also fine. The loaded summary makes it seem as if misinformed or misguided people are resisting the moral imperative to move to Git. Leave the Bolshevism at home. Actually, I have moved a couple of projects from SVN to Mercurial rather than to Git, since I think that Hg's better for my particular needs.
There is no such thing as a "die hard" subversion fan. People use subversion because they already use subversion. Not because they are fanatical about their choice. Which sets them apart from people who go for Git, Mercurial, etc. it puts subversion people roughly in the same group as CVS people.
It's hard to be fanatical about the philosophy of "if it ain't broke, don't fix it"
“Common sense is not so common.” — Voltaire
Well if you use a broken browser you get a broken site.
There's nothing keeping you from using git and writing a script to pull code from each peer when it becomes available.
Have you tried to report a bug? I know my browsers all work fine here; then again, I haven't used that Internet Explorer you mentioned for quite some time.
Anyway, I'm fairly sure it's not the site, but the browser. Reporting a bug should get it solved fairly quickly, especially since proprietary software is developed in a significantly better-organized fashion, with proper quality control and teams of programmers devoted to stamping out bugs.
Ignore this signature. By order.
Here's why my projects use Subversion and not git. In no particular order, with no claim of absolute truth, this is just how I see it:
I guess it depends mostly on the last point - your needs. If you're Linus and you're writing a kernel, git is probably your best choice, because it was built with that in mind. If you're working with a normal team on a normal programm, Subversion is probably more suited because it was built for that. Anywhere inbetween - your decision. :-)
Assorted stuff I do sometimes: Lemuria.org
Retch.
Get your own free personal location tracker
I couldn't see any way to do this in subversion.
We had someone commit a bunch of DVD .iso files to our repo, and I cannot figure out how to go back and permanently remove them from the repo.
http://strongdynamic.blogspot.com/2007/08/expunging-problem-file-from-mercurial.html
It seems mercurial can do this.
When using CVS, I can just log onto the server and rm -rf the relevant directory. I really miss that feature in subversion.
Instead of comparing features and quirks, what are the strengths and weaknesses of GIT/Subversion/etc. within development processes? What would fit better in, say, and SEI level 5 environment as opposed to an open source world like the Linux kernel or Apache HTTP Server? In an environment where you you must have a clear audit log, not just of the primary branch or release branches but even the development branches, then Git is going to lose out big-time.
Doesn't exist? In a clean-room implementation you must be able to prove to code auditors that a feature or certain code path did not spring fully-formed like Athena from the head of Zeus.
I'm not dissing Git, but this myopic discussion of "My feature is philosophically better than yours" is missing a whole range of areas of comparison.
I'm normally all for newer better systems, but I have to agree... CVS > SVN because of branching/tagging.
So, wait... You're running CVS and directing its stdout to a new file "SVN" in the current directory?
Or are you saying CVS is a higher-valued number than SVN? Couldn't you simplify that and say C > N? I suppose that's only safe if you assume S and V are non-negative and that complex numbers and matrices don't figure into this...
Bow-ties are cool.
Git vs. SVN is more of a philosophical argument than a technical one. Git encourages disconnected operation and independent work more, while SVN tends to pay off the most if you're working regularly in lockstep with your team and everybody has a clear picture of what everybody else is doing. Not that you can't work on one kind of project with the other software, but it's more painful.
There are bona fide technical issues you'll probably encounter no matter which one you pick, but those issues are trivial compared to the productivity you'll gain/lose by choosing the right one for your project and your (team's?) way of working.
For you specifically, since you work with Rails, use Git. Everybody else is now, so it'll make dealing with other Rails developers easier. Most of the junior Rails folks we looked at recently (and haven't hired) are familiar with Git but not SVN.
For everybody else, if you're a solo/freelance developer working by yourself, the choice doesn't matter at all. You don't really run into the major differences between the two until you start collaborating with other people.
Game... blouses.
I guess second that. I may be able to figure out Git command-line commands, but the sales guy who checks his documents into our SCM sure won't.
Any serious SCM needs to have a super simple, intuitive, easy to use GUI. And IDE integration. And shell integration. And web interface. And webdav access.
Here's one particular usage I'm not sure SVN can keep up with (or maybe it can--I've been out of the SVN loop)...
I go on the road quite a bit for vacation, but sometimes work gets in the way. For the times I'm out of internet range for periods of a few days, (I know; what is this--the South Pole?) it's great to clone the repo to my laptop before I hit the road.
That way I still get version tracking and branching and all that good stuff. I just push it back when I get a net connection. To be safer, you can always back up your local repo to a thumb drive or something.
It totally beats just having a copy of your source files that you check back in later.
It's kind of funny, isn't it? Git's 2 biggest advantages are that it's fast and it's distributed. And then people go use github which is neither.
Do you even lift?
These aren't the 'roids you're looking for.
I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.
Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits.
Not true. I hadn't even heard of git one month ago, but we just set up a central repository system. Actually we already had a central git repository (on github) before I started working here, but that meant everybody pushed their commits into the same repository, which the guy responsible for deployment to production didn't like: he wanted to keep it stable and only accept changes he approved of.
So now everybody has his own fork on github, pushes commits to his own fork, and the guy merges those forks (branches, basically) back into the main repo. Since merging is trivial, this works out very well. Everybody can access everybody's commits without messing with the stable trunk or making a big mess of things, because git does all the heavy lifting for us.
Having used SVN before, I was very skeptical about git until less than a week ago. Now that I've seen what it can do, I'm a believer.
I don't think a 200-person project could possible manage with svn, but for up to say, 5 people, I just like the fact that it's simple and doesn't try to solve every problem. Revision numbers are simply increasing numbers that I have a good feel for, and there are only two versions I need to think about (working copy and repository) instead of 4+ (working copy, index, local repository and remote repository(s)).
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
Git fails because of the lack of integration. Until it has that, it does not fit my needs.
I love IDEs too (although I haven't found one yet that doesn't suck). I admit it would be nice if NetBeans would detect which files have been changed and which have been added (shouldn't be too hard to implement, I think), but beyond that, a command line interface works perfectly fine in combination with an IDE.
What's more, it fails to start with because they didn't consider that in the first place.
Yet people are working on integrating git with IDEs. And let's face it, the Eclipse plugins for SVN aren't all that great either.
milquetoast (n)
sissy: a timid man or boy considered childish or unassertive
wordnet.princeton.edu/perl/webwn
Because I knew everyone else was just about to google it like I just did.
My caps lock key is wedged, you insensitive clod!
Most people don't get why the integral of "e to the x" is so funny. Most math majors don't have a sense of humor.
So as a cmd-line user who only uses centralized repositories (with only a couple of other developers), what kind of benefits would git provide over subversion?
Git would allow you to revert individual commits by other developers. That's something SVN will never be able to do. We just implemented a setup where each developer has his own repository on github, forked from the main repository on github. This makes it very easy for the guy with the final responsibility for deployment to decide which code he accepts and which he doesn't, while everybody else can easily accept whichever commits they like.
This is really useful when some people are committing crazy shit, or some people are working on a big new feature that shouldn't go live yet, while others are working on bugfixes that should go live as soon as possible.
Doing this with SVN is bloody hard. With git it's trivial.
Recently I set up a subversion repository for hobby projects of mine and other general stuff that I wanted to access on several machines. The main repo is set up on my server.
I've tried setting up GIT before, but it seemed overly complicated to get access to from all of my machines.
So the question is, is subversion right for me? None of these comments have really addressed anything closet to my situation it seems.
My UID is prime... is yours?
Last year I nearly had to murder somebody because he was pushing git for 6 guys in the same office producing a web site that released weekly. I agreed that git was cool, and were I doing a distributed project, especially an open-source one, I'd love to use it. But I just couldn't see the value for a bunch of guys who worked off of trunk, were on the same LAN, had exactly one version in production, and checked in between a few times a day and a couple times a week.
If people feel there is a value for a team in that situation, let me know, as I'd love to hear about it.
We're in exactly the same situation, and have recently become convinced of the superiority of git. I didn't even know git until 3 weeks ago (when I started working here), but now I'm a believer.
Ofcourse there's also a disadvantage to using git: you have to be a genius to understand how it works. SVN is far easier to understand. But even then, it's hard to fuck up git, and easy to fuck up SVN.
Read some of my other comments here for more details.
We've been through CVS, SVN and finally GIT when developing our code internally for a big open source project before opening it.
Git actually requires changing the mindset for developers from producing the code to producing the patches.
This is an excellent description from one of my colleagues and I think that Git is ideally made for making patches. Patches are what are valued and needed in the open source world while it is still often different for the corporate inner projects.
When we were going to open source the code and understood that we'll have to behave like it is done in the open source, send patches to committers, Git became a natural choice although the central repository of the project is in SVN (Apache repository). Developing patches is different from developing the code in a small sized team. Git offers absolutely the greatest power to operate with code changes (patches) locally than any revision control that I've seen.
The article misses a tremendously useful feature of Git called "rebase". It is useful when you develop some changes against a trunk that changes while you work on your code locally. You make some local commits and to make them synchronized with the current state of trunk it is necessary to rebase them on the new version. Git does it by far in the most convenient way I've seen applying all of your local commits one by one and asking to resolve conflicts when it is necessary. Of course it requires some discipline to commit locally in small portions, but it is easier than "merging often" with the trunk of development than subversion handbook says. Merging is often tedious and it is way easier to just commit small changes to a local repository than every time resolve the same conflicts when "merging often". You never have to resolve a conflict again after you've done rebase with Git.
I didn't find performace on windows so bad. Cygwin port works ok, not so fast as on Linux, but it is good enough compared to subversion update. TortoiseSVN has to keep a separate cache to make windows performance decent. This cache is sometimes renewed and slows down a system for a long time if your checked out repository is big enough. All of subversion transactions like "svn log" require server interaction while Git is lightning fast. So I think even if filesytem performance of Git to clone or checkout may not be so good on Linux it is compensated with no delay to do every day commands like log, annotate, diff, etc.
I would generally not choose git because I think it is harder to use than several other distributed SCMs based on a very similar model. It is true that last I checked git was faster than any other one, but there is one that is pretty close to git in performance and is much easier to understand and use, and that's Mercurial.
Need a Python, C++, Unix, Linux develop
How is it that no one has mentioned http://www.github.com/ yet? Does any similar offering exist for svn? No need to answer, as it simply can't.
GitHub is the bee's knees people.
Re-reading my post, I realize I sound like a ridiculous shill. I'm not, I'm just a guy working on an open source CMS in Ruby on Rails (http://www.ansuzcms.com).
Oh yeah, my company's new site is in progress at http://www.ansuzcms.com3000/ if anyone cares to let me know what they think of the design. The content's pretty much at nothing right now.
-knewter
I like to use git because I find it easy to make a branch for testing out some new code, and easy to merge the branch into the trunk if I want to keep it. Here are some aliases I wrote that cover pretty much all the git I use. If I decide to change version control systems, I can change the aliases. alias vca='git add .';
alias vcb='git branch';
alias vcc='git commit -a';
alias vcd='git diff';
alias vcm='git merge';
alias vco='git checkout';
As for choosing between git and subversion, why not try both? It's pretty unlikely that somebody will tell you what you like best. You have to find out for yourself. Considering that they are free software, easy to install, and pretty easy to use, you can try both and see if one of them seems better to you. I tried both, and I chose git. But I don't mind if other people use subversion, RCS, SCCS, or whatever they feel like using.
Subversion and git have different models. Subversion has a client-server model with the repository accessible by http. Git uses a distributed model, with each user getting their own copy of the repository, and the possibility of merging things from one repository to another. This might make git work better if the users' computers aren't always able to connect to a remote repository.
Try them both, see which one you prefer.
This is /. where knowledge and experience are not required, and almost frowned upon, when stating an opinion.
Engineering is the art of compromise.
A "simple text editor" dev environment stopped being useful or productive back in the 90s.
Good thing that emacs and vim aren't "simple text editors". :D
At least, not if you know how to use them.
But I'm still a fan of the UNIX philosophy - a program should do one thing, and do it well. A great editor, a great debugger, and a great SCM tool - what the heck can't you do with that?
The wise follow a damned path, for to know is to be forsaken.
In Git (and in Bzr, but not in Mercurial), there doesn't have to be a 1-1 mapping of named branches between each copy of your distributed repository.
That bit about mercurial is actually not true. You can have multiple branches on a single repository, and switch between them easily:
http://hgbook.red-bean.com/hgbookch8.html#x12-1650008.5
Try checking a 500M file into git, mercurial or bazaar sometime.
Um. In git's case, it makes a copy of the 500 MB file, and calculates its SHA1. And that's all it does.
So when you check into SVN, it doesn't bother with the SHA1?
Pirate Party UK
If the Rails community is going to GIT, you better believe the long term best way to go is Subversion.
I find it mildly ironic how often git is used as a centralized rcs given that it was built and marketed as decentralized.
I only work in a team of 4-5 people and even we use it centralized, pushing your changes to a git server when you are done. I can't imagine working in a team where you had to constantly tell people you'd made a change and they needed to pull it.
And don't even mention deployment, stuff like capistrano or something along those lines has to pull changes from somewhere. I'd rather have deployment mechanism pulling from a central server than the repo of whoever it was doing the deploying.
Kids, you tried your best and you failed miserably. The lesson is, never try. -- Homer J. Simpson
git is dead in the water and this post nothing but advertising tripe.
I spent a couple hours reading git doc and still did not understand how to do simple things. svn by comparison was trivial to bring up and use. Maybe it's just me. A decent set of documented use-cases is probably all I lacked, but why do I have to develop my own?
The I in IDE is where the UNIX philosophy fails. Sure, simple and small programs are good. The problem is that not every task is simple enough to be solved by a single program. At that point those small programs get hard to use. And at that point a program that integrates all of them is handy. To make domain specific, common and complex tasks easy to do.
Take for example refactoring. That is renaming of a variable or function. You could do that with sed. But imagine you do some OOP and you have two classes that both have a "foo" function. You soon realize that this name is stupid and you want to change it. But for class A you want to name it different from the name in class B. How would you solve that with sed?
That is the point where you need a tool that has a quite good understanding of the language you are programming in. Even a syntax aware tool won't suffice. You have to parse the code to detect the correct functions you want to rename.
I am no vim or emacs guru, and I don't want to become one to solve such a simple problem. And I have my doubts that vim or emacs could even do that, how do they even know which code files to scan? That might involve some find or grep and sed.
The problem was easy, the solution should be easy, too.
Ugh. Subversion 1.5 has 'merge tracking', if you want to call it that, in the most primitive fashion imaginable. Subversion has no way of tracking merge history in its essential structure, and certainly no way to do anything between multiple repositories.
With Git, it's all content addressable, so you have complete flexibility, no matter the order or sequencing of branches and merges, across any number of branches and/or repositories you care to have, foreign and domestic.
I used Subversion for several years with a large project, and it was a lot better than when we were using CVS, and I was rather fond of it.
But Git is *so* *much* *better* with regards to branching and merging that it's not even funny. Add in fantastic tools like 'git gui', 'gitk', 'gitweb', and public project hosting sites like repo.or.cz, and there's no contest.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Comment removed based on user account deletion
How Bazaar Has the Model Right
One of the points the article makes is that Git uses hashes to store blobs based on their content, whereas Bazaar uses UUID's based on content. The argument being that hashing algorithms are susceptible to being deprecated in the future. eg. recent MD5 collisions.
-metric
Git is easy to understand if you don't pretend its svn. People who work for me that didn't use SCMs before pick up on Git naturally and with ease. People coming from cvs/svn (like myself) had a harder time. At the bottom of understanding git is just having at least the slightest inkling of how it works, and that it is nothing like svn or cvs. Git is much more like having your own snapshotting file system per-project directory, and you do searches through your snapshots to look at the history of various strings and files. Git's initial implementation never even maintained per-file information of any sort (except the file content during a snapshot).
My advice is use git, it will get fast on Windows (and currently isn't all that slow), and Mercurial is descent, but it doesn't do branching as well as git (try deleting branches) and _is_ slower where it counts. Seeing as git will get fast, and your repo history is going to stick around for a while, the transient state of git's performance in Windows shouldn't concern you that much.
Mercurial is noticeably slower when doing recursive diff between repo versions, it is noticeably slower when doing merges. Initial checkin and checkout are file copies, so its no surprise that mercurial and git (and any descent source system) will go at roughly the same speed, but these benchmarks are useless to you (who cares how fast you can do a 'cp'?).
See:
http://www.infoq.com/articles/dvcs-guide#sectionbench
In addition, not that you care now, but git's design is more likely to get file system support at some time, given how it works compared to mercurial (as I said, git behaves like a snapshotting file store).
After using distributed version control for a very short time, I decided I will never go back to something centralized like Subversion. Only with a DVCS do I can:
- Get work done, with complete repository access, anywhere. On a train. In the rain. In a box. With a fox. Anywhere, any time, even when the network goes down or while I'm thirty thousand feet above an ocean.
- Create as many experimental branches/clones as I like, without making them visible to anyone else or cluttering up any shared namespace. (This is especially nice for capturing checkpoints when I have a lot of large, interdependent changes to make and the project won't work until they're all finished.)
- Get perfect, complete, automatic repository backups as a side-effect of working on a project. It's as hassle-free as I could ask for, and restoring is equally easy.
After quite a bit of reading, I ended up choosing Mercurial. After a year or so of using it regularly, and occasionally checking in on the other DVCS systems, I have always been glad of my choice.
Git was a contender, but is notoriously non-intuitive and awkward to use, and has never been a good fit on Windows. (I try to avoid Windows, but some of my colleagues still use it, and some of our projects are necessarily cross-platform.) Mercurial is similar to git in design, features, and speed, and is also very easy to use and works well on every major platform. Linus even called it out in his version control rant.
Bazaar was a contender, and I like their sponsor (Canonical), but didn't seem focused on performance enough for my liking.
More points for Mercurial:
- The folks on the email list are very knowledgeable, friendly, and helpful.
- It is very easy to extend.
- It has the blessing of some very large, high-profile projects. (e.g. Mozilla, OpenSolaris, Java's OpenJDK)
To the git users who use the gitk GUI for browsing revisions, Mercurial has a clone:
http://www.selenic.com/mercurial/wiki/index.cgi/HgkExtension
To the user who posted about the Tortoise GUI for Subversion, here's a link for Mercurial's equivalent:
http://tortoisehg.sourceforge.net/
To the user who posted about Trac integration, Mercurial will work too:
http://trac.edgewall.org/wiki/TracMercurial
Also of note, Version Control Blog occasionally links to some interesting articles:
http://www.versioncontrolblog.com/
I've been trying to get my boss to convert from cvs to svn. Now I'm going to have to convince him to switch to svn and then git...
IMAGE VERIFICATION IS EVIL!
When the subversion server is down, work stops.
When the git server is down, work continues.
You should watch some of Linus' talks on git if you still think that subversion works the way you 'want'. Subversion does not, in particular, handle merges very nicely (or even at all). And, there's nothing that subversion does that a properly configured git installation cannot do better. [Everything sv can do, git can do better!]
The real question you should be asking is, "Do I want centralized or decentralized version control?" Unless you project involves hundreds of developers who are strangers to you, you don't need to go with a decentralized model. Linux is a special case that needs a decentralized version control system where changes are fed up through a chain of trust. Most projects don't need this kind of a model.
It is far easier to get clueless users using source control when they an easy-to-use and friendly client such as TortoiseSVN. I wouldn't even try to get the artists on my team to use the command line for anything, because they WILL screw it up. With TortoiseSVN, clueless users at least have a chance of using source control correctly.
Migrating from Subversion to one of the Distributed VCS's isn't free - it takes a bunch of time for someone to work out how to perform the migration without losing any history information, and then all of the current developers need to come up to speed on the new tool. Some development processes may also need to be adapted.
It also isn't simply a question of "Should we move to Git?", but whether you should move to git or mercurial or bazaar or something else.
So there's an upfront cost to pay in evaluating your options, and an upfront cost in doing the migration, and an upfront cost in reduced productivity as people get used to the new way of doing things.
That all feeds into answering the basic question: "Is it worth the time and hassle?"
If you only have a fairly small team doing commits and you don't branch often, then subversion + svnmerge may be an adequate solution. There's also the option of offering mirrors of the main subversion repository via other version control systems.
Python, for example, is experimenting with DVCS's by mirroring the main subversion repository:
http://www.python.org/dev/bazaar/
http://code.python.org/hg/
http://python.ca/nas/tmp/git-notes.txt
THAT is the question: Darcs is so much more user-friendly that it's MORE LIKELY to be used, among a bunch of non-hardcore people ( including writers for versioning their documents ).
Darcs vs git, what are the pros, what are the cons, from the perspective of someone who isn't the developer of either of those 2 projects...
Anyone?
We work on one branch per developer, typically. This was intended to help keep trunk clean, keep us from stepping on our toes, but avoid the dangerous habit of just not checking something in until it's ready.
Then, we got sick of the amount of time required -- both of us and of SVN -- to do merges. We pretty much decided we were going to move to Git -- but the time to do so wasn't available, so we instead switched to SVN 1.5.
It was nice, at first. It's really nice to be able to just fire off an "svn merge ../some_branch" and let it do its thing. It was only slightly slower than in 1.4.
Then it got slower.
And slower.
Now, there's a good chance a merge will take a solid 20 minutes or so to even start, and several minutes after that to finish the merge -- during which time, you can't really touch that branch. But exactly the same number of merge conflicts as before.
Turns out, all SVN 1.5 does is track merge history. This makes the output of "svn blame" somewhat more useful, and (so far) only slightly slower. It also means it can automatically figure out the range of revisions which need to be merged from any given branch, by looking at the merge history to figure out which revisions have already been merged.
Which means it saves you having to look at the log and find out those revisions for yourself. It won't save you from a single merge conflict, no matter how stupidly easy such a conflict would be.
Now, since it's possible that:
- You could merge from trunk
- I could merge from trunk
- You could make a bunch of changes
- You then merge back into trunk
- I merge from you
- I then try to merge from trunk
In that example, since I merged from you earlier, I already have the changes that you merged from trunk.
If you think about this a bit, the implication is that an SVN 15 merge has to consider almost every merge that has ever happened. Even if the branch in question was deleted long ago, SVN will dig it up, just to make sure you don't have those commits.
And this is actually the best they can do. I believe it would take a significant restructuring of SVN to do better.
So, if you only have one or two branches, and merging is a rare (monthly) occurrence, you'll probably be fine. For awhile.
Eventually, you'll probably do what our team ended up doing -- record mergeinfo in the commit log, and merge manually, by specifying a range of revisions -- and, to make it go faster, specify --ignore-ancestry.
In other words, to make it go faster, we have to explicitly force SVN 1.5 to merge exactly the way SVN 1.4 does.
So, my suggestion is, don't bother. It's a smooth enough upgrade, but it offers very little of value.
You'll probably end up doing what we're doing now: Staying on trunk, mostly, or on a longer-lived feature branch, using git-svn to make it slightly less brain-dead.
Don't thank God, thank a doctor!
Try checking a 500M file into git, mercurial or bazaar sometime.
Um. In git's case, it makes a copy of the 500 MB file, and calculates its SHA1. And that's all it does.
Oh, no, that's not all. Try *changing* said 500MB file, and watch the difference in backend repo size. :3
~ C.
I also like the central server aspect,
Git doesn't imply that you can't use a central server. It just makes it possible to not need a central server.
What happens to your productivity when your SVN server goes down? What if you want to take a laptop somewhere without ready Internet access?
and I just have to keep that backed up.
That is simply not a concern with Git. Every checkout contains the project's entire history -- yet manages to take up less space than a single Subversion checkout.
In other words: As a side effect of simply using Git, you have one full backup of your repository per developer.
If your central server goes down, it's simply a matter of throwing up a new server and having everyone push. And until the new server comes up, you can share directly with each other, over whatever network's available.
it's easier to manage subversion with the one main server.
It sounds very much like you haven't tried with Git. Play around a bit on Github and see what it's like.
Don't thank God, thank a doctor!
or more likely mercurial (since it's more portable)
if it could do all of the things svn did, and then some, all without being harder to use.
However, from what I've seen, it adds new features at the expense of breaking things that used to work easily.
On svn, it's possible to have large repositories. Furthermore, it's possible to only check out part of the repo if you only want to work with that part, not so with git or mercurial.
On svn, it's easy to create a central repository that lots of users can check into to keep their work synchronized. Is this even possible with git?
The idea that you don't need a central repository is rediculous with code bases that have a high enough developer density. i.e. high developers over size of code base. If lots of developers are all working on the same sections of code, it's important to keep in sync with them even if they aren't on your team.
Furthermore than idea of a pull based model is rediculous for everythign except code reviews. In day to day use I dont' want to have to iterate through all the members of my team to sync in their changes. That requires too much communication overhead for such a simple task.
Talking about Slashdot itself, or the way Slashdot works is *not offtopic*. Use your mod points wisely or I'll come round your house and steal your washing.
Maybe it's just me, buy watching someone else talk as a method of determining what I want sounds suspiciously like sitting down to discuss a timeshare proposal.
Just because SVN doesn't do what Linus wants, doesn't mean it doesn't do what I (or anyone else who uses it) want. Admittedly, I use it for my personal hobby projects. SVN "server" that runs local on my notebook, so the repository goes everywhere I go anyway. I'm the only developer, so I don't care what anyone else might want with the code. All I care about is that I can keep track of what changes I've made, so that if something breaks I have some obvious places to look.
Everything I've read in this whole discussion seems to center around Linus's talks, distributed repositories (or whatever they're called in git, as someone who has barely registered it aside from hearing about Linus's talk, I'm not really up on what the lingo should be), speed, and branching and merging. Linus might prefer git, but this mere mortal works with SVN just fine. Being able to make a local repos is pointless when the repos IS local. Speed? Small projects, not needed. Branching and merging? I guess I'll deal with that if i need to, but for my single-developer setup a tag is probably more appropriate.
As for the actual question posed by the submitter, it accomplishes what I need. When I worked for a small consulting firm, it served our needs fairly well, and our svn admin was comfortable with using the tools available to handle the "back-end" details of merging. I don't remember ever having a project big enough that we branched, just having to walk through a code change with him when he was creating tags for release (I was only working on documentation, and our manager had to use my laptop one day to commit a fix).
Noone seems to have mentioned that SVN is like CVS in that it is files based whereas GIT is branch based. This means the diffs are on the whole branch, not just a file. You don't look at file history in GIT. It doesn't make sense. You look at branch history. Also if you rename a file or move a file to a different folder GIT knows this. SVN doesn't. You don't have to tag a whole branch with GIT because every checkin is a whole branch. I've used both and I prefer GIT. I particularly like the ease of creating branches that can be either local or can track a master repository and then merged in. Making branches just seems so easy in GIT. I agree that the windows gui tool (gitgui) isn't very impressive on but it works. And the command line interface is very nice. I *do* love the graphical branch history display on windows. If it's good enough for the Linux Kernel it sure is good enough for the small projects I work on.
Why don't these distributed VCS dumbfucks support pushing to centralized VCS repos and everybody would be happy?
I don't usually judge things by their trendiness and/or marketing hype (and I doubt few geeks are different in this respect). If a man offers good points, then they are indeed good.
I listened to his talks and he pretty clearly defined what is wrong with SVN and why git is better (to a rational scientifically-minded audience). Those benefits may not be as applicable to a single-dev setup, but I didn't think the post I responded to described such a setup either.
Thank you for putting all of that so well.
"developers", "programming", and "story" seem to be auto-generated tags.
try checking a 500M file into git, mercurial or bazaar sometime
That's true, unfortunately. About twice per year I try out all the newcomers, because I would really like to use a distributed vcs. Unfortunately they ALL fail badly on big files. I'm using svn much like a versioned filesystem and really like it for that. But if you're working with aerial photos and laser data, it means you're dealing with LARGE files. Subversion is fine with that. And with TortoiseSVN I can even have laymen use it without problems.
I'm open to suggestions for an (open source) alternative.
I find it curious that nobody mentions keywords.
The reason why I did not switch to GIT when Linus created it is that it was not possible to add auto-modifying keywords. With keywords, the SCM can physically modify your files, in precisely marked spots, to indicate the version level of a file in the actual code. I really like this aspect.
At the first publication of GIT, I remember Linus holding a strong stance against keywords. This is why I did not convert to GIT (I am a one-man-company and I do not need to collaborate on code: I need SCM to keep all old versions and changes).
(You can read Linus' stand on this, for example, in this e-mail from 2006)
In the current GIT faq they mention that keyword substitution is "not recommended", but they then point to the man page of gitattributes, which, disappointingly, does not mention keywords.
This is why I keep using SVN. I need my sources to hold within themselves an easily trackable age indication.
That's a very good point that also applies to bzr.
(I personnaly use bzr and I've never used git but I think that most bzr functionnalities are available in git).
I use bzr over svn because when I start a project, I don't have to create (or have) a server, I don't have to make a complicated import. I just go in the folder and type "bzr init". VoilÃ, my project is under bzr.
I use bzr because I can commit even when I'm offline and I'm not afraid of small untested commits because they are local. It's really a lot more confortable.
I use bzr because if I want to test something on an existing project, I know that branching and merging will be trivial. By comparison, just look at how many pages the branching chapter of the subversion book has.
I use bzr because I cannot use svn without breaking my local folder every week. I very often delete and rename file with using the svn command. I move a complete folder and, poof, all is broken. It takes a lot of time to repaire. Most of the time, I end by doing a new checkout and manually copying the modified files in the new checkout. When it happens, I hate subversion. Really. I also cannot recommand svn for non geek users. Bzr simply works and I never had any problem like that.
Finally, I use bzr because I don't care about my VCS, I just use it. Bzr is still young. The documentation is far from perfect. Using it is easing but advanced stuff like setting a shared server over Apache are still not well documented and not features complete but, still, if you take a few days/weeks to learn it then to use it, you will wonder how you have been doing before. Really
Ploum.net.
In the linked article there is a misuse of branching in Subversion.
In fact, you need to branch only to maintain old versions, not to create new features!
When developing new features, you operate directly on the trunk, so that inconsistencies pop up as soon as possible.
If a feature should be ported to a branch, then there is the need of a merge, but not the opposite!
> Bazaar will let you work as if it were Subversion, for example, with a central server, lightweight local checkouts (with no history).
> It will also let the same group of people work offline. Or heavyweight checkouts that can be offline, but commit to the server by default.
Yes, yes & yes!
This is one of the areas where git is lacking. Being able to commit offline is nice, but the central backup of svn, bazaar etc is a very very nice feature which you get for free.
Ever tried to get non-technical people to use the command line? It's almost always a futile (and infuriating) experience. So if you have a multi-disciplinary team working on a project (coders and artist, designers, etc.) then GUI integration is a must. In my experience you can teach them how to use visual tools, but there's no chance in hell they'll learn to use the command line.
So even though git has a lot to go for it from a technical standpoint, it's lack of easy-to-use GUI and IDE integration is a major showstopper in such cases.
"Also if you rename a file or move a file to a different folder GIT knows this. SVN doesn't."
It knows this in the version I use.
I think a lot of people who criticise SVN are not using it well, or are not up to date in their version.
Can git be used for versioning files scattered across the filesystem? Basically I want to be able to do `git status` (or equivalent) and get a list of changed files.
You've already switched anyway...
are you going to switch back if you like the reasons people give you? baahhhh baahhhh
I see discussions like this all the time: "Emacs is better than Vim", "Git is better than CVS", ...
And I must say, I don't get it. Why is this stuff so important? I've seen people type really fast in their super-editor, and commit and branch their code faster and more efficient then you could ever imagine. But I've also seen the same people produce crappy software while doing this.
So, is this question really that important?
If you work in something other than the software industry and thus if even your IT managers are not developers:-
The article totally misses the point. The only really important feature (for me) git has over svn that I know of is better merge tracking, and this should be improving starting with subversion 1.5 (haven't tried it yet myself as our server hasn't been updated).
The "local copy of the repo" thing is good for certain environments, where there are a lot of developers using a very decentralized workflow. I'm sure it's optimal for the linux kernel but it's not everybody's piece of cake.
Also it seems the guy is really unfair on svn, so git can do diffs for you, well duh. Hell cvs can do that too.
SVN might be too simple for what you need. On the other hand, GIT might be an overkill. Mercurial stands between the two in terms of features and learning curve. Mercurial has a few more commands than svn, but it's a whole lot more powerful.
And keep in mind that branch management is a LOT easier on Mercurial than on svn.
Reading up to chapter 8 in this book may help you decide :
http://hgbook.red-bean.com/hgbook.html#hgbookch1.html
An IDE would have caught that typo.
Switch back to Slashdot's D1 system.
Just my $0.02
$0.02? I guess you haven't heard of inflation yet.
http://xkcd.com/378/
From the GIT web site:
Java GIT/Eclipse GIT (repository) originated by Shawn Pearce is a Java GIT library and plugin for Eclipse IDE, in very early stages of development. The site no longer seems to have the plugin. Robin Rosenberg has recently been working on history and compare views for the plugin. David Watson contributed GUI for branch handling and commit. Progress is slow but steady. A EclipsePluginWishlist has been started as a roadmap of features. A page has been started to follow development: EclipsePlugin.
Conclusion: Not ready for production. See you next year.
Mercurial aka. hg is another distributed VCS/SCM. It has much in common with git (although git *might* be a little more kick-assier in places), but may come in handy as a better SVN replacement because it does work well on Windows, brings very nice Explorer integration through TortoiseHg and is supported by Trac, too, so your toolbox might look pretty much the same. Don't know about integration into Eclipse and others, though.
For those who don't think about version control systems every day, when he says "bzr" he is talking about Bazaar, the VCS Mark Shuttleworth supported for Canonical because he didn't like the other VCS.
"The documentation is far from perfect."
Unfortunately, Canonical is supporting the usual Open Source tradition of communicating poorly, forcing everyone to use weeks of their time to learn something new, instead of having one person spend weeks writing good documentation. In a lot of ways, Canonical is just the same old pig, wearing a bit of lipstick.
Just learning to use git, I just did something I'm personally amazingly impressed by:
I was writing a new (small) feature for our website. I'd found an interesting solution, and implemented the first part of it, and put it in a commit. Then my boss (correctly) decides that perhaps this feature isn't such a good idea after all, and other stuff it more urgent.
I like my code, so I don't want to throw it away. But I don't want to push it to the central repository either. So here's what I do:
Branch (which is currently exactly the same as the master, including that last commit).
In master, revert that last commit. A revert is a new commit that undoes an old one (and it can be very old). 'git show-branch' shows my master to be based on the branch (because the master's graph contains the branch's HEAD).
If I were to push my master now, the central repository would show two commits, the second of which undoes the first. I'd rather have the new feature just in the branch, and not in the repository's master at all. So I try something else instead. And here is where we're going to reverse causality:
Using 'git reset --soft branchname^', I reset the master to the state before the last commit in the branch. I keep my local uncommitted changes, but the last two commits (the new feature and the revert of it) are gone from my master. This is what I want to push to the central repository.
So where's the magic? 'git show-branch' suddenly shows that my branch is now based on the master, when it was the other way around a moment ago. But now the branch is ahead by one commit, so technically it's correct.
I'll now continue to commit in my master, and if we ever decide what to do with the new feature, I can easily merge the branch back into the master and continue from there.
If you're managing a single, centralized, monolithic project which references no external projects, git is for you. Its simplicity can make basic operations a joy to use. Some things which in Subversion are just plain broken (like, say, updating your local copy) are handled sanely by git in ways which will never lose work.
If you're managing code which references external projects, or multiple inter-related projects, Subversion is still the winner. Git has very little support for such things (it's coming along, but is currently young, hack-y and broken). Git is not designed to manage the relationships between "different" projects, and having them all in one place with Git requires just as much kludge with Git as it would take to merge changes from one SVN repository to another. (which Git reportedly excels at, though it seems to handle the parts which are sticky in SVN by ignoring them)
I came out a bit pro-svn-leaning, I suppose. For the record: I use git at home and svn at work. Tried using git-svn at work but it was completely unusable with multiple interrelated projects. My point is: Git is good in one situation and svn in others. I would much prefer to use git for everything, it just doesn't cut it for everything.
As for the article:
Point 1.1: "Git creates a full repository with this command."
Not an advantage. Creating a full repository is a different way of working, but as git's only options are "the whole history of the world, full-featured OMGEverything" or "shallow copy with no features", I would call this even with SVN. If Git adds the ability to "fall back to fetching from remote" when it needs extra information from a shallow copy, Git will have an advantage here.
Point 1.2: "With each branch, no new files are created in the project file hierarchy on your system. Since you have a full local repository"
Here is a man who does not know how branches work in SVN. Just because SVN has a horrible interface is no excuse for using an even worse one. svn copy long-ass-url long-ass-url, followed by svn switch long-ass-url is not only "correct" here, but a more accurate pairing with what the git command is doing. (The "git way" of doing what the svn command does is to create a hard-linked copy of the local clone).
Git also has the "disconnected operation" advantage here.
Point 1.3: "With Git, we only push our work to the server AFTER collaboration (more below). With Subversion, it all hits the server."
There are several readings of what this means. Some interpretations mean "You have stupid workflow practices", while others are clear git advantages. I love not pushing every little change until I'm ready for a nice rolled-up commit which will show clean and meaningful diffs to anyone browsing through history. But he could mean "I don't know what branching is for and made a blog post about it". I'll go with the "git is awesome" interpretation, though.
Point 1.4: "Again, no file system work. Since we're using a local repository, we let Git handle the details of removing the branch."
I fail to see how "I deleted it from the history, so I want all my local changes to be fucked with" is an advantage.
Point 2.1: "The key thing to note in this and every step is how we switch between branches."
You're doing it wrong. But I won't go into it because Git is fucking awesome at this. You just did a really really really bad job of showing why.
Point 2.2: "Git will 'float' uncommitted changes."
Stop using convoluted terminology and say "Git makes branching easy. Oh wait I said that already."
Point 2.3: "Same as 2, but shows the 'git stash list' feature."
Uhm, thanks? This has nothing to do with "git vs svn". Also, you're still doing it wrong.
Point 3.1: "Git has a nice feature to create 'patches.'"
Given that the first listed step is "check your email for patch", the whole argument is invalid. I can e-mail
-- 'The' Lord and Master Bitman On High, Master Of All
The Version Control Blog references an article, Choosing a Distributed Version Control System that is almost a year old, but has interesting comparisons. That article says the documentation of Bazaar is good. Is that because the others are even worse?
I agree.
While there may be certain situations that require distributed versioning, for my main project (the BlinkenSisters Jump'n'Run) subversion does its job perfectly. Combined with an IRC autobuild bot, automated checkin-reporting to our central mailinglist and not having to merge branches all the time, subversion is a very handy tool. A central repository also forces the combined team to fix bugs quickly.
Also, the windows explorer integration with TortoiseSVN is very nice for developing on the windows side of life.
I think, the main difference between central SCM and decentral SCM is how the developers work: Subversion is for teams, GIT is for individuals working on a common project. Sound similar, but it's quite different: A team lives primarilly through communicating with each other, a group of individual coders by creating patches (which does *not* help getting into team spirit).
Look, this thing is totally safe! Built it myself, you know. You just press that button like this and then turn that lev
Then I would like to thank and congratulate you on painstakingly copy-pasting every lower-case letter in your reply in from somewhere else =)
These bash tab-completions make subversion much nicer to work with: http://paste.ideaslabs.com/show/2UYMIdYr0p
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
Uhh... you know, you *can* do both. I use TortoiseSVN + Visual Studio at work (yeah yeah... :), and it works just fine. I have absolutely no compulsion to use an SCM within my IDE... in fact, I would contend that a specialized tool designed to work specifically with the SCM is going to inevitably be more effective than something tacked on to my IDE.
Find out what Version Control systems the developers of Subversion and Git were using when they wrote their code.
The author of the article makes several mistakes in his subversion examples which lead me to think he has not used svn seriously (making his judgement questionable) or he is deliberately skewing things towards git (making his judgement questionable.
In "Endless, Easy, Non-File-System-Based, Local Branches":
Task 1: the subversion box should be empty. Nobody checks out a whole Subversion repository or even (a whole project including all branches) in normal usage.
Task 3: the workflow is a valid workflow for Subversion, but it's more normal (for small changes certainly) to work on the trunk and distribute a diff file for review before committing the change at all. This is the model that the Subversion developers themselves use for Subversion.
Task 4: why would you want to delete the branch in the repository? In Subversion you'd just do "rm -rf /local/copy/branches/B" or equivalent and leave the repo as it is.
In "Stashing Temporary Work"
Subversion has the command "svn switch" to switch a working copy between two repository URLs. Alternatively, you can just check out the branches to different places on your file system and have them all there at once.
The author's example of why the git approach is better seems to have been contrived based on the way one particular editing tool works (he doesn't say what happens to a TextMate project file if your branch deleteds files from under it (or adds them).
In "Collaboration Before Public Commits"
Svn can produce patches based on the differences between your working copy and any arbitrary revision / branch too. There's absolutely no reason you can't use the exact same workflow that the author suggests for git.
Philiospohically, I am inclined towards a central repository especially for large team projects. I realise you can do that with git, but as a project manager on a large project, I'd still be nervous knowing that it is possible for a developer to have quite a lot of committed work that exists only on his laptop or that there might be prima donna developers that consider their personal repository to be the "master".
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Yet people are working on integrating git with IDEs. And let's face it, the Eclipse plugins for SVN aren't all that great either.
I don't know about all that. The Subversive plugin for Eclipse works quite well, but this is mostly because it's simply duplicating the CVS functionality already in Eclipse but using SVN instead. Okay, so it sucks at merges, but then SVN sucks at merges anyway.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I dare you to poll some high level kernel coders on what they use to write code with.
You'll probably get a lot of vim and emacs answers, and not a whole lot of Visual Studio ones ;-)
As quaint as I personally find IDEs in general, they often annoy me more than they help me and a good editor is much more important than the integrated extras.
- Michael T. Babcock (Yes, I blog)
... what's your point?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I agree that git's merging is much better. In fact, comparing subversion's merging with git's is ridiculous. However, most people don't really make branches (until they start playing around with a distributed version control system). Until you've used a system, like git, where you can create a separate branch for each new idea and still merge your branches sanely merging doesn't seem like that big of a deal. Heck, many git users don't even take advantage of git's merging ability. To them git is just a much faster subversion (with less tool support).
As far as tools go, Subversion clearly has the edge. repo.or.cz is nice, but everyone has subversion support, and so do all of the IDEs and other tools that you are probably interested in. What's more, it's trivial to use git, hg, or bzr as a front end for Subversion.
For a non-technical user, Subversion really is hard to beat. It's trivial to set up a Subversion server that looks to them just like a network drive. They don't even have to know that they are using a versioning file system. Combine that with the fact that Subversion will happily version even ridiculously large files means that you can use Subversion in situations where git simply won't play at all.
For my own projects, I use bzr (I have used git in the past), and I understand why Linus feels so strongly about subversion. For source code git is impossible to beat (assuming that everyone that needs to use the repository doesn't mind using a command line client).
However, there's a reason that Subversion is more popular than git, and why it is growing in popularity faster than git. Most people don't care about merging. They just want a straightforward user interface for a versioned file system.
This is really useful when some people are committing crazy shit
This isn't a technology problem, it's a social problem. To solve this, you actually TALK to the developer in question and tell him to stop committing crazy shit. If he has a problem with that, you revoke his commit access and require he submit patches to you for review.
Not only is that roughly the same amount of work (the main difference being that, instead of pulling from someone, you have to wait until the out-of-band push to you), but you teach someone an important lesson: how not to be an asshole in a group collaboration setting.
Having said that, there are lots of other awesome reasons to prefer git over svn, easy/quick local branching being one of them, as you mentioned.
Xfce: Lighter than some, heavier than others. Just right.
I had to struggle with merging in Subversion a good while before I ever took much notice of any of the newer generation of revision control systems.
I'd create a branch (so easy!), do some development on it for awhile, and then discover that I was S.O.L. when it came time to merge it back into my trunk. Likewise, we have four instances of a project in development running here at the lab, two for development and testing of the application and business rules, one for user test, and one for production. I wanted to have each instance's code in its own branch in Subversion, but Subversion provided no help in managing merges from the dev instances to test and then production.
Git makes that easy.
You're absolutely right that Git isn't a perfect replacement for Subversion, though. Git compresses its repository to an amazing extent if you are working with source code, but only a few Word and Open Office odt files in a documentation directory in our Subversion tree wound up massively dominating the Git conversion of that tree.
We had to learn to use git filter-branch to sculpt and shape Git copies of our Subversion repository in order to produce a set of well-defined Git repositories that could reasonably stand on their own.
As far as tools, I actually find the tools on Linux rather superior to what I've seen with Subversion, with the exception of Eclipse. On Windows, Git definitely lacks anything like tortoisesvn. We still use Subversion for a Windows-only project, for that reason.
But I think that the trends are positive for Git. The energy and enthusiasm around Git, both 'plumbing' and 'porcelain', is profound, and the richness and simplicity of the underlying Git model facilitates that.
And, I must confess, I've spent rather too much of my life struggling to get Subversion built and installed. Getting Subversion integrated into Apache has at times been very 'special', shall we say. I like that Git-http merely requires the standard mod_dav module (which was developed in significant part by Subversion contributors, as I understand it).
The deficit Git has, the deficit Git always will have, is the relative level of conceptual difficulty involved in using it. I don't ever expect Git to fully replace Subversion or CVS, just like CVS never fully replaced RCS.
But I know which one I'd prefer to be stuck on a desert island with.
(And, hi! from another 4 digit Slashdotter. Fancy user number you've got there. ;-)
- jon
Ganymede, a GPL'ed metadirectory for UNIX
But even then, it's hard to fuck up git, and easy to fuck up SVN.
Really? Seems the opposite to me. You can very easily wipe out large amounts of local history with git, and if you haven't pushed it elsewhere, it's gone, forever. Git's tools and poor documentation make it easy to shoot yourself in the foot. With SVN, after you commit, your changes are pretty much immortalized without direct repository editing on the server.
Granted, it's sorta the same -- with both git and svn you can lose data if you don't push/commit to another location -- but git more or less encourages you *not* to push anywhere until/unless you need to, and provides a host of potentially 'dangerous' tools that work on your local repository that svn doesn't provide.
Xfce: Lighter than some, heavier than others. Just right.
I use git at work because we were told to, but I am actually quite fond of it. I've even started using it to keep track of personal projects at home.
I like it because it has pretty good documentation and I can figure out most of what I need with a quick search, and because it generally does what I want when I want it to.
We switched to git from cvs about a year ago, and I am much happier for a few reasons that will also apply to subversion:
1) Repository info is only stored in one place, so you don't ever need to search out all of your CVS or .svn directories
2) Local commits make it easy to check stuff in whenever you need to, and then make it pretty (with git rebase -i commitid) before pushing to a central repo (assuming that's the model you are using)
3) There is a two-stage commit. You have the working tree (aka working copy), which is what you are editing, the 'index', which is where the changes you want in the current commit go, and the actual repository, which holds commits. With that extra step in between, you can check in only the parts of a file that are relevant to the current commit (with git add --patch filename). I have a tendency to do a bunch of editing everywhere, forgetting to commit, and then go back to make multiple commits of discrete features/bugfixes at the end of the day. I'm pretty sure you can't do that with CVS, and although I'm not sure about subversion, it would surprise me if you could do it there.
4) The repository keeps track of changes across multiple files, instead of tracking each file individually. That makes applying a bugfix from another branch really easy, since you don't need to hunt down every file that was modified by it.
So anyway, I'd suggest sticking with git, but there's no harm in trying other systems; you never know, what I like and what you like may be completely different.
Bravery is not a function of firepower.
~J.C. Denton (Deus Ex)
But even then, it's hard to fuck up git, and easy to fuck up SVN.
Really? Seems the opposite to me. You can very easily wipe out large amounts of local history with git, and if you haven't pushed it elsewhere, it's gone, forever. Git's tools and poor documentation make it easy to shoot yourself in the foot. With SVN, after you commit, your changes are pretty much immortalized without direct repository editing on the server.
You're comparing apples and oranges here: a situation where you go out of your way to destroy git history with one where you go out of your way not to mess up SVN. Not pushing git commits to another machine is comparable to never commiting anything in SVN. If you lose your local machine, you're fucked.
On the other hand, in SVN it's actually quite easy to edit the repository by hand and destroy stuff. With git, at the very least, you know it's been messed with because the hash codes are wrong.
Granted, it's sorta the same -- with both git and svn you can lose data if you don't push/commit to another location -- but git more or less encourages you *not* to push anywhere until/unless you need to, and provides a host of potentially 'dangerous' tools that work on your local repository that svn doesn't provide.
I don't see how git encourages you not to push. With SVN, pushing incomplete code to the trunk may fuck up other people's work. With git, you can always push to your own github space and merge that into the central repository when it's finished.
This is really useful when some people are committing crazy shit
This isn't a technology problem, it's a social problem. To solve this, you actually TALK to the developer in question and tell him to stop committing crazy shit. If he has a problem with that, you revoke his commit access and require he submit patches to you for review.
That may prevent a valuable developer from contributing in the future, but in the mean time you're still stuck with crazy shit.
Git gives you the tools to solve this problem.
Not only is that roughly the same amount of work
What exactly is the same amount of work here? Blocking development compared to fixing a problem?
(the main difference being that, instead of pulling from someone, you have to wait until the out-of-band push to you), but you teach someone an important lesson: how not to be an asshole in a group collaboration setting.
You assume only assholes commit bad code. Good programmers can fuck up too.
I'm getting the impression that for SVN the world consists only of assholes and perfect programmers. I think the majority of programmers are neither. You need to be able to recover from mistakes, not blindly hope they don't happen and cripple your business when they do.
My company uses subversion as the centralized source control system - was MS Source Safe when I started here, but we migrated over not long after - but I use git with git-svn locally on my machine because I find the branching and merging/rebasing in git much easier to work with.
Rare scenario? That's the norm for me. My primary area of work involves very large changes to a rendering engine on a large simulator project. Changes that can often take me 3-5 weeks to get to a point where I'm satisfied with them. Unfortunately, due to the nature of the changes, the system will probably be completely broken for the first week or two of this change. If I don't branch, I can't check in my code, as that would break things for the other developers. By not checking in my code, I lose the benefits of revision control on my own work, leading to a "WTF!? This worked yesterday!!!" scenario very quickly, which can be difficult to recover from if I forgot about some small change I made while half asleep the previous morning. Having my own development branch (or indeed, several different development branches each for different features) was immensely helpful at my previous place of employment. Subversion made doing that a dream, and Trac made keeping track of the relationships between branches a breeze. My current employer uses CVS exclusively... And the absolutely asinine way of handling branches in CVS has led to me not using separate dev branches... Much to the chagrin of myself and my coworkers...
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
As a policy, my company uses subversion, more for our windows users than anything, so myself as a linux dev use both. Using git, it's relatively simple to use checkout and merge into an svn, while still maintaining your local repo and branches for all its intents and purposes. I personally love the implementation of branches in git and can't do without it, as I'm generally working on 2-3 new features for software at the same time, and sometimes have to leave broken code hanging around for days at a time before I can finish what I had started. If I put that into the main svn, I'd probably be shot by the rest of the dev team.
Each has it's own place in life, and sometimes living with more than one is always an option. Use whatever model suits your company or environment best.
Um. In git's case, it makes a copy of the 500 MB file, and calculates its SHA1. And that's all it does.
Oh, no, that's not all. Try *changing* said 500MB file, and watch the difference in backend repo size. :3
Try git gc. It initially stores the repository unpacked as a speed optimisation, on the assumption that the latest commits are likely to be accessed frequently. When you run the garbage collection tool occasionally, it 'packs' the commits into delta-compressed files. Why not do it straight away? Because the packing is an expensive process, it defers carrying it out so that when you git commit it completes as fast as possible to allow you to get on with your work.
I hope that explains the 'lack of performance' you perceive.
Pirate Party UK
I'm aware of "git gc", and I've actually had the rare opportunity to talk to Linus about why git does some of the things it does, and I understand all that, but when one has as many repos as fd.o does, it's the kind of thing that becomes a recurring annoyance. And I had to point that out.
~ C.