×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Practical Reasons To Choose Git Or Subversion?

kdawson posted more than 5 years ago | from the while-we're-at-it-do-you-like-vi-or-emacs dept.

Programming 667

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

667 comments

Blah (5, Funny)

Anonymous Coward | more than 5 years ago | (#25457871)

You can have my cvsroot when you pry it out of my cold dead fat hands.

Re:Blah (2, Funny)

HTH NE1 (675604) | more than 5 years ago | (#25458675)

My workplace still uses RCS. We also use XEmacs 19.13, a 1995 codebase last built in 2001.

Keyword: Herd (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25457893)

Still using CVS, not using "Rails" ...oh look a shinny.

flamebait (-1, Flamebait)

simonharvey (605068) | more than 5 years ago | (#25457915)

Can the slashdot admin add the flamebait tag to the story. I think that it would be the proper thing to do here.

Kind regards

Simon

Re:flamebait (1, Offtopic)

arotenbe (1203922) | more than 5 years ago | (#25458043)

Just for reference, it's the Slashdot users who add the tags, not the editors.

Re:flamebait (1, Redundant)

Emb3rz (1210286) | more than 5 years ago | (#25458135)

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.

Re:flamebait (-1, Offtopic)

Bert64 (520050) | more than 5 years ago | (#25458275)

Because it's massively outdated compared to every other browser out there...

It's not like other browsers are doing anything proprietary and nonstandard, everything is documented and microsoft simply chooses not to implement the published standards.

Re:flamebait (3, Funny)

MrMr (219533) | more than 5 years ago | (#25458461)

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.

Windows. (5, Interesting)

scott_karana (841914) | more than 5 years ago | (#25457931)

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.

Re:Windows. (5, Funny)

Just Some Guy (3352) | more than 5 years ago | (#25458393)

Git is an excellent piece of software, but Windows performance is not so great.

Git could paint your house and buy you a girlfriend, but that wouldn't help Windows.

IDE Integration (5, Interesting)

FortKnox (169099) | more than 5 years ago | (#25457937)

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.

Re:IDE Integration (4, Insightful)

Tester (591) | more than 5 years ago | (#25458077)

Clearly, you've never used git to think that some UI can make subversion usable.. Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).

Re:IDE Integration (5, Interesting)

dubl-u (51156) | more than 5 years ago | (#25458713)

Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).

Simpler solution: stop merging reasonably-sized branches.

I know that's not reasonable for every situation, but about 90% of the time I see people doing lots of branching and merging, it's a response to screwed-up organizations or dysfunctional personal relationships. I saw one team move to git from subversion because, at the root, a couple of developers were arrogant assholes and their manager was a chinless milquetoast who let them get away with it.

That's not to say git isn't awesome for certain situations, mind you. But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.

What about Hg, then? (1, Informative)

Anonymous Coward | more than 5 years ago | (#25458225)

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.

Re:IDE Integration (0)

Anonymous Coward | more than 5 years ago | (#25458353)

most of the items that git 'claims' to be better on is something IDE plugins fix

You just keep telling yourself that. Offline capabilities, possibility of distributed workflows, commits as _real_ atomic changesets, speed... All features that SVN will never have.

Personally, I'm never going back to SVN if I get the choice.

Re:IDE Integration (0)

Anonymous Coward | more than 5 years ago | (#25458611)

"commits as _real_ atomic changesets"

Please expand on this. Are subversion commits not really atomic?

Command line is easier (2, Informative)

mangu (126918) | more than 5 years ago | (#25458443)

most of the items that git 'claims' to be better on is something IDE plugins fix

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.

Re:Command line is easier (0)

Anonymous Coward | more than 5 years ago | (#25458551)

Using the -a flag with 'git commit' is discouraged. It's mostly just there to help out people more familiar SVN/CVS. You should always be explicit with what you are committing.

Re:IDE Integration (1)

morgan_greywolf (835522) | more than 5 years ago | (#25458529)

Right on the money. Although I'm aware of Git a Eclipse plugin, last time I looked at it, it sucked maturity-wise. Subversion and CVS have been supported on Eclipse and for other tools, including Microsoft IDEs, for quite sometime, so...those are the source control systems I use, too.

Re:IDE Integration (2, Informative)

trjonescp (954259) | more than 5 years ago | (#25458589)

Unless you are coding in something like vi or emacs, I don't use the command line for my source control.

I use emacs and never have to use the command line either. emacs is an IDE just like any other. It's just not graphical.

Re:IDE Integration (4, Insightful)

Haeleth (414428) | more than 5 years ago | (#25458779)

I don't use the command line for my source control. IDE Integration means a lot...

You feel free to wait around for "integration". The command-line client is already nicely integrated into my IDE, which is the most mature, most stable, and most flexible one in widespread use: Unix.

Re:IDE Integration (1)

nautical9 (469723) | more than 5 years ago | (#25458789)

We're facing this at my company too. We're just about to upgrade from SVN 1.4 to 1.5 (far better branching and merging), but it's still painfully slow, which means developers are less likely to do one-off branches to try some experimental feature. Instead, they make the change to trunk, which can make back-tracking out harder. Git is lightning quick for this kind of thing, and allows them to work off-line and sync up later.

The problem with Git is the utter lack of visualization, plugins, and integration with other tools.

For example, we use Fisheye as a web-interface to our SVN repository - it's a great way to watch the codebase, or query it to drill down to see specific changes. There's an svn-git gateway tool, but it's rather rudamentary.

If there was a similar tool, plus a proper Eclipse plugin, I think we'd make the switch. Git's speed is just unbelievably fast.

go with Perforce (2, Informative)

flannelboy (344272) | more than 5 years ago | (#25457965)

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.

Re:go with Perforce (4, Insightful)

32771 (906153) | more than 5 years ago | (#25458125)

>Note that Perforce is free for open source projects.

Yeah, so was BitKeeper and that used to really work too.

Re:go with Perforce (2, Interesting)

nuttycom (1016165) | more than 5 years ago | (#25458325)

Ugh. I've used CVS, SVN, Perforce, Darcs, and Git over the years. Perforce was far and away the worst of the lot.

Whose bright idea was it to make the clientspec an unversioned artifact? In the company that I used Perforce at, which shall remain unnamed, it took me two weeks just to assemble a clientspec that would give a checked-out version of the repository that would actually build. Every developer in the place had their own personal flavor. What a ridiculous nightmare that was.

Git is far and away the best version control system I've ever used. Sure, it doesn't yet have decent IDE integration, but the command line interface is simple and gives you more power to rearrange your repository as needed than anything else I've seen. I love the fact that local development branches are so cheap; using independent branches for each of the features I'm working on at any given time helps make sure I don't let excessive coupling between subsystems creep in to my code, and merging (and rebasing, and rearranging commits) is faster and more painless than with any other system I've used.

Re:go with Perforce (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25458601)

Whose bright idea was it to make the clientspec an unversioned artifact? In the company that I used Perforce at, which shall remain unnamed, it took me two weeks just to assemble a clientspec that would give a checked-out version of the repository that would actually build. Every developer in the place had their own personal flavor. What a ridiculous nightmare that was.

To be fair to perforce, I have used it at various different companies, source tree sizes, etc. and I have no idea what you are talking about.

Making a client spec is super easy. Type "p4 client" and map the revision control directory to somewhere on your local machine.

So your previous company may have done something foolish that you are now blaming on Perforce.

I've worked with 5,000,000 line source trees in perforce and it is extraordinarily fast. It integrates to virtually every IDE and Editor out there, and it has a fantastic command line if that is your tool of choice.

It works on many many platforms, including the usuals (Window$, Linux, Solaris, Mac OS X, BSD, etc.)

Perforce's strength is that it makes it really easy to branch and then merge.

So if you work with a lot of developers, and you need to do parallel projects, Perforce is incredible at this.

It's definitely worth a look.

Re:go with Perforce (1)

davester666 (731373) | more than 5 years ago | (#25458689)

Yeah, way back, Perforce didn't version clientspecs. And it still doesn't by default. But since about 2002 or so, they've supported a separate 'spec' database, that if an administrator created it, Perforce would populate it with branch, client, depot, group, and user changes.

What I couldn't believe is that subversion couldn't track branch points. The end-user had to manually 'remember' which revision of each file was branched from to aid in merging later. Sure, some clients added their own support for tracking this info, but it sure is nice that Perforce does that all for me.

Haven't used git, so I can't compare it with these.

I even use Perforce at home, using the free 2-user license.

Re:go with Perforce (2, Informative)

liquidpele (663430) | more than 5 years ago | (#25458791)

What I couldn't believe is that subversion couldn't track branch points. The end-user had to manually 'remember' which revision of each file was branched from to aid in merging later.

Added in subversion 1.5

Drag perforce out back and shoot it (0)

Anonymous Coward | more than 5 years ago | (#25458383)

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.

my choice (5, Informative)

liquidpele (663430) | more than 5 years ago | (#25457973)

I went with subversion because our programmers are mostly just website guys, and it had the most user friendly tools (for windows and mac) and was the easiest for them to learn.

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. Yea, I know GIT is distributed, but it's easier to manage subversion with the one main server.

Just my $0.02

Re:my choice (3, Insightful)

sohp (22984) | more than 5 years ago | (#25458109)

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.

Re:my choice (1)

liquidpele (663430) | more than 5 years ago | (#25458163)

Yea, we have a very high turnover rate (won't go into why), so keeping the latest code in a central place that I control is very important. Of course, if I ever leave they are screwed ;)

Re:my choice (3, Interesting)

onefriedrice (1171917) | more than 5 years ago | (#25458511)

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.

Re:my choice (1)

dubl-u (51156) | more than 5 years ago | (#25458795)

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.

Re:my choice (2, Insightful)

befletch (42204) | more than 5 years ago | (#25458365)

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.

Re:my choice (3, Informative)

Jason Earl (1894) | more than 5 years ago | (#25458437)

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.

Integration in common tools (3, Insightful)

oever (233119) | more than 5 years ago | (#25458005)

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.

Re:Integration in common tools (3, Informative)

Yokaze (70883) | more than 5 years ago | (#25458347)

The other dvcs Mercurial: Tortoise [sourceforge.net], Eclipse [vectrace.com], Netbeans [netbeans.org]
I don't see, why the workflow has to become more complicated for server-side things like Jira and Confluence: you simply create a automatic server-side conversion from your central dvcs repository to a svn repository for those tools are done with it.

Because... (0)

Anonymous Coward | more than 5 years ago | (#25458007)

Because Subversion "Just Works".

Re:Because... (2, Insightful)

corprew (24232) | more than 5 years ago | (#25458367)

I've been using Subversion largely through the eclipse plugins for a while, on a couple of different platforms. I would characterize the Eclipse integration (Subversion) as fairly mature, and it has exhibited recovery for me across a few different hilarious network failures, which caused me difficulties (and delta corruptions) on the commercial products i'd used previously.

Benefits of Subversion:
1. It's been working for a while, the last thing I need to do with my copious spare time is switch over to a new VCS mid-project.
2. MacOSX version that works without having to deal with endless recompile/experimentation. Right now, it's a PITA to get git working under MacOSX.
3. It's easier to back up a central server than it is to get developers to back up their machines on a regular basis. Who wants to risk losing code?
4. I'm working for a startup. Right now, I'm evaluating VC systems on one basis -- and it isn't novelty, it's whether it does a job in an appropriate way without taking resources away from doing other high priority tasks. GIT (as of a month ago at least), hadn't reached that level of seamlessness.
5. Good tools exist that non-technical people can use to check things in and out of SVN on a variety of platforms.

--Corprew
(and for those wondering, SVN works fine with the free AptanaStudio plugin that lets you write rails/ruby in Eclipse)

Re:Because... (1)

waveclaw (43274) | more than 5 years ago | (#25458493)

Because I am the only developer or user of my code?

Seriously, I really really like the model of GIT has for group development. But when by myself I can just cp filename.ext{,.bak} if I'm feeling lazy.

And that is the key. I am typically the only developer on most of my projects. If I hadn't gone out of my way to learn to version control files on my own, I wouldn't have even known about it until my first real programming job. I still work with people who either use tape backup or the cp .1 .2. .old .bak to manage their files after decades as developers or sysadmins.

FTA:

Youâ(TM)d like to work on each of your 4 features A, B, C, and D independently and somewhat in parallel,

And I already mastered branching using other VCSes. This is just Yet Another Version Control Syntax [blogspot.com]. (YAVCS? Sounds like a disease...)

You start working on A and youâ(TM)re about 100 lines of code into it when you get stumped on a math function. The math wiz on your team is out for the day and youâ(TM)d rather not continue until you consult him. ...
So now we can work smoothly between multiple branches without worry of the consequences of interruption.

Working on my own personal projects means I don't have a 'math wiz' to ask...

Git offers power by putting collaboration up front before commits are public for all to see.

Most projects on sourceforge.net have 1 developer. But then most are essentially dead so probably not the best.

To quote Linus Torvalds on Subversion vs Git:

Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do cvs right. No comments.

Git is wonderful for group work. And if you are introducing version control to a group environment you can probably start out with it.

For some of the solo developers, subversion is just CVS with nicer features and the old, familiar workflow.

To quote Linus again:

If you like using cvs, you should be in some kind of mental institution or somewhere else

Ever hear the story about the sanitarium? It was for insane people only, so to be safe they had the contractor build it inside out.

Neck and Neck (4, Funny)

Anonymous Coward | more than 5 years ago | (#25458023)

I can honestly say that I have no preference of one over the other; having only just heard of them both by the OP.

not 1:1 (5, Interesting)

sohp (22984) | more than 5 years ago | (#25458025)

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.

Re:not 1:1 (1)

MemoryDragon (544441) | more than 5 years ago | (#25458291)

Actually the main proble with GITs approach compared to SVN is. SVN means one central repo, GIT means every developer has a mirror of his local repo lingering in the net and devs pull from everywhere. In SVN the integration must basically be done on the fly by everyone committing, with build processes and continous integration servers trying to verify the project state being in order. GIT basically enforces the model of a central integration branch an and integrator doing the integration work all the time. This might be a feasable model for some, like it is for the Linux guys, but in many projects this is not viable. But git is flexible enough that you even can do the central approach, and I dont see any reason why not, the tooling is very flexible and definitely faster than SVN (with the downside of having a complete repo mirror on your local hd) The biggest issues GIT currently faces, simply is the lack of a decent windows port, neither cygwin nor mingw are ideal, the Windows port must be really native without any emu layer on top! And the lack of any tool integration into the major ides (VStudio, Eclipse, Netbeans, Intellij) while some integration is there, it is far from being really usable and in case of eclipse driven forward by one person outside of the Eclipse consortium! (Same goes for Netbeans afair, this is done also outside of Sun)

Real programmers (5, Funny)

David Gerard (12369) | more than 5 years ago | (#25458037)

Real programmers type cat | cc and get it right the first time.

Re:Real programmers (5, Funny)

Waffle Iron (339739) | more than 5 years ago | (#25458147)

Real programmers type cat | cc and get it right the first time.

Some of us don't have to cling to safety blankets like that. We prefer the simplicity of cat > a.out

Re:Real programmers (1)

32771 (906153) | more than 5 years ago | (#25458233)

Wow! Does that even work? I mean how do I enter binary codes into cat?

I know this has to work somehow - I'll read the man page.

Re:Real programmers (2, Funny)

dreamchaser (49529) | more than 5 years ago | (#25458245)

Meh. Talk about safety blankets. Real programmers use magnets to set the bits of the executable on the disk manually.

Re:Real programmers (1)

cromar (1103585) | more than 5 years ago | (#25458489)

Don't be a wuss. Develop mutant powers in a nuclear accident* and burn the pits into optical media with your newly acquired laser eye.

*Some trial and error may be necessary.

Re:Real programmers (1)

CBravo (35450) | more than 5 years ago | (#25458647)

Yeah!

And they use the sun and a magnifying glass to burn their DVD's.

For BluRay you need to filter the light with a prism.

Windows & Documentation (4, Informative)

vladd_rom (809133) | more than 5 years ago | (#25458057)

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.

Re:Windows & Documentation (1)

MemoryDragon (544441) | more than 5 years ago | (#25458213)

Unfortunately yes, having Windows clients for development, some solaris AIX Linux or you name it OS for deployment is pretty much standard in the corporate world. If you are lucky you might get granted so much freedom that you are allowed to install a VM or a second partition, but most of the times you wont! Cygwin is a helper there, but a real GIT port as well as Eclipse integration would be vital for wider adoption!

Linus on Git vs CVS/Subversion/Bitkeeper/etc (5, Informative)

MrFreezeBU (54843) | more than 5 years ago | (#25458061)

How odd that I was just watching a talk that Linus gave at Google. Link to the talk [youtube.com]

Re:Linus on Git vs CVS/Subversion/Bitkeeper/etc (5, Informative)

doug (926) | more than 5 years ago | (#25458205)

Randal Schwartz, the Perl guru, gave a more detailed presentation on git, also at google. It has a lot more meat on its bones, and gives examples of using git.

http://www.youtube.com/watch?v=8dhZ9BXQgc4 [youtube.com]

Re:Linus on Git vs CVS/Subversion/Bitkeeper/etc (0)

Anonymous Coward | more than 5 years ago | (#25458633)

yeah but he's not linus. how dare you?

CVS all the way baby (1, Flamebait)

i_ate_god (899684) | more than 5 years ago | (#25458067)

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.

Re:CVS all the way baby (4, Informative)

MemoryDragon (544441) | more than 5 years ago | (#25458173)

Sheesh tagging and branching really is the weak point of CVS while SVN does both pretty well! SVN just does it differently but unless CVS finally can make real tags or branches instead of doing full file copies I will stick to SVN. Sorry to say that CVS has some nice points, mostly being faster than SVN but thats basically it, everything else is way better done by SVN, especially tagging and branching! Git does both operations more along the lines of CVS with real tags and branches instead of hardlinking, but in the end the end result is the same, lightweight tags and branches, while CVS has heavyweight tags and branches!

Re:CVS all the way baby (1)

einer (459199) | more than 5 years ago | (#25458377)

I'm normally all for newer better systems, but I have to agree... CVS > SVN because of branching/tagging. I don't have a good, rational reason for thinking this, other than it works how I think it should and SVN does not. Perhaps my brain is calcifying (it is getting to that age), but I'm glad our shop never switched to SVN.

Tagging in SVN (0)

Anonymous Coward | more than 5 years ago | (#25458699)

Why would you tag in SVN? Since I started using SVN, I stopped tagging code. Instead I just use the repository version.

Re:CVS all the way baby (1)

DerWulf (782458) | more than 5 years ago | (#25458349)

We use CVS at work mainly because eclipse had support for it inbuild for quite sometime and the only thing that *really* bothers me is that it doesn't handle deletion in terms of versioning. Aside from that I don't even know why I might need other source control ...

Re:CVS all the way baby (1)

nuttycom (1016165) | more than 5 years ago | (#25458391)

Git makes branches actually useful. Repeated merges under CVS or SVN (well, perhaps not the latest SVN, but every one before it) are the stuff of nightmares, with changes conflicting with themselves all over the place.

Re:CVS all the way baby (0)

spottedkangaroo (451692) | more than 5 years ago | (#25458415)

I didn't see any particular reason to move from CVS to SVN either. The only reason I could see was support for directory changes. But they screwed up everything else.

Give git a try. It's a big change and it's a frustrating first few days, but before long you're like: why didn't I try this before???

(Hg is the same way, afaik, but I never tried it.)

The only caveat is windows. If you work on windows, be prepared for a slow cygwin port... gaarh. Still worth it. CVS sucks, SVN sucks the same but different. Try git.

Re:CVS all the way baby (1)

Just Some Guy (3352) | more than 5 years ago | (#25458509)

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.

You have to be joking. Branching and tagging is so cheap under SVN that I actually do it now, and SVN support nice minor features like, say, renaming files and atomic commits. To the best of my knowledge, SVN is a strict superset of CVS.

Re:CVS all the way baby (1)

dvice_null (981029) | more than 5 years ago | (#25458545)

Branching is what Git is about. I have never seen a system where branching would be so easy. Every time you start working with a new idea or fix, you make a branch and start working with it.

But I found out that it is impossible to tell people what Git is about, you need to hear it from Linus to understand it (sorry MrFreezeBU for stealing your link, but I have seen it earlier and I think it really explains it well):
http://www.youtube.com/watch?v=4XpnKHJAok8 [youtube.com]

Re:CVS all the way baby (1)

jhol13 (1087781) | more than 5 years ago | (#25458587)

You really should look into distributed VCS, like Git. CVS sucks as a version control system as there is no way to atomically add changes to several files. Besides it has no comprehension of merge (neither does Subverion as of 1.4.X).

Svn really does not need tags, you can use "copies" for that, they actually work better (but requires the user to obey unforced rules).

I have used Mercurial and the merge just works, it makes everything so much easier.

I have not used VCS, but in PVCS merging was just huge PITA, the system did not have the concept "merge" (if you made a branch there was no way telling the system there had been a merge. Sure you could run diff3/merge + commit, but in the VCS you would not see it).

Even for one man projects distributed version control systems kick ass (two computers or merging or ...).

Doesn't Matter (1)

foo fighter (151863) | more than 5 years ago | (#25458101)

It doesn't really matter whether you use git or subversion as long as you use vi as your text editor.

Re:Doesn't Matter (1)

Bill, Shooter of Bul (629286) | more than 5 years ago | (#25458283)

I was thinking along the same lines. It certainly does remove some major points of emphasis for the second two points ( reducing the number of project files for an Ide, and extra file system work). But take another look in detail of the two workflows. It's looks like its just less painful all around to have a greater number of branches with Git. The only concern I would have would be file space. yes I know its cheap, but If I used git to its utmost branching potential , I think I'd fill up the drives pretty quickly.

git is distributed, svn not (1)

Simon (S2) (600188) | more than 5 years ago | (#25458105)

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.

Go with Bazaar (4, Interesting)

bbn (172659) | more than 5 years ago | (#25458115)

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/ [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.

Re:Go with Bazaar (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25458175)

I agree with you that bzr has most of the same features as git and a nice user interface.. And still, I don't think it matters. Every major open source project is switching to git. Because git is SUPER-fast (not just fast), and it has a greater mindshare and Linus is behind it. And the git user interface is being improved very fast, and its becoming more and more easy to use (without losing the power). I even heard Shuttleworth say that he would drop bzr completely when Gnome will to git (he said "if"..)

Git and SVN (5, Informative)

MemoryDragon (544441) | more than 5 years ago | (#25458143)

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)

similar thoughts (2, Interesting)

Speare (84249) | more than 5 years ago | (#25458149)

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.

Re:similar thoughts (1)

Jason Earl (1894) | more than 5 years ago | (#25458571)

The size of the repository is not the problem in this particular case. Both git and mercurial assume that it is safe to have several copies of the object in memory at any given time. In other words your 2GB files are going to cause git and mercurial to bomb out with memory errors (unless you are on a really big machine, I suppose). From my own experimentation on a machine with 2GB of memory both of these systems can handle files up to about 500M before failing. However, with files above 50M both of these systems become slower than CVS or Subversion.

The advantage of distributed systems is that they are far better at merging files. If you aren't merging files then these tools are probably the wrong tool for the job.

3d party tools - Trac and Tortoise (5, Informative)

Anonymous Coward | more than 5 years ago | (#25458165)

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...

Reasons Not to Switch (0)

Anonymous Coward | more than 5 years ago | (#25458179)

  • Subversion will use less space on indivual developer's computers disks.
  • Using a central server will give you an obvious place to go to for a system of record.
  • Using a central server will let you check user ids based on an external authentication system to make sure you can blame the right person when they break the software.
  • You don't use branching that much and can safely ignore the dumbest decision ever on the part of the subversion developers

Does it matter? (4, Interesting)

Jeff Hornby (211519) | more than 5 years ago | (#25458191)

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.

I have considered Git but... (3, Interesting)

shellster_dude (1261444) | more than 5 years ago | (#25458235)

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.

Re:I have considered Git but... (1)

slartibart (669913) | more than 5 years ago | (#25458685)

svn has no merge tracking. That's a pretty crucial feature. Leaving it out results in vast numbers of workarounds, extra procedures, policies, and headaches. Failure to follow these strictly results in a hopeless mess. Need I say anything else about svn? I haven't used git, but I hear it at least solves that problem.

Git isn't the only distributed revision control sw (0)

Anonymous Coward | more than 5 years ago | (#25458361)

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.

IDE integration, ant tasks and windows tools (1)

andy1307 (656570) | more than 5 years ago | (#25458405)

Eclipse plugin, ant tasks for builds and TortoiseSVN. Most developers I work with don't use command line svn.

How about GIT vs Mercurial ? (2)

m.dillon (147925) | more than 5 years ago | (#25458439)

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

To paraphrase Linus.... (1)

Wee (17189) | more than 5 years ago | (#25458459)

Only wimps use source control. Real men just upload their important stuff on ftp, and let the rest of the world mirror it.

-B

svn or git (1)

l3v1 (787564) | more than 5 years ago | (#25458485)

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.

Because it works (1)

Alioth (221270) | more than 5 years ago | (#25458525)

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.

My own opinion (prob. very controversial) (1, Interesting)

jrothwell97 (968062) | more than 5 years ago | (#25458543)

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.

two points for svn (1)

tclark (140640) | more than 5 years ago | (#25458563)

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.

Well (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25458645)

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.)

mercurial (2, Interesting)

BountyX (1227176) | more than 5 years ago | (#25458711)

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.

Look who you're asking (0)

nsayer (86181) | more than 5 years ago | (#25458727)

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.

Git makes backups easy (2, Interesting)

togofspookware (464119) | more than 5 years ago | (#25458793)

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'.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...