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.
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
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
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 :)
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.
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.
[
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...
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!
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?
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.
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.
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)
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.
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.
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.
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...
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.
You've obviously never worked on a programming team.
The best reason to use CVS or Git is the situation where multiple programmers are touching the same file(s) at once and you need to both commit. Also, the blame tool on SVN lets you easily tell when any given line of the code was added and why (see the commit message). The SVN repository I work on professionally has well over 25K commits...try managing that with a bunch of copies and text files!
(I've done the versioned tarballs for a project I worked on alone...never again!)
-- Political fascism requires a Fuhrer.
Actually the lack of atomic commits in CVS is reason enough for me not to touch it with a ten foot pole. CVS was good enough when it was the only competition on town (It still is better than VSS and RCS) but nowadays basically all revision control systems having atomic commits one way or the other. CVS being put on hold and have been put on hold for so many years, I would not touch it anymore and would consider even to move old repos over to newer systems. There are so many systems around that there is no single reason to stay with CVS, unless bad habits you dont want to get rid of!
cp sucks at merging.
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.
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.
Uhh, ok.
$ cd tortoiseSVN
$ svn info
Path:
URL: http://svn.collab.net/repos/svn/trunk
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 33826
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 33826
Last Changed Date: 2008-10-21 15:16:27 -0500 (Tue, 21 Oct 2008)
That was tough. I think I broke a sweat.
You can leave comments on snapshots with versioning filesystems? I'm asking, I really don't know, haven't ever dealt with them, but any version control system that doesn't have comments is nearly worthless to me. I really need to know why my developers make a change as looking at the code for a bunch of changes across several files does not always result in the clearest picture of a change if you don't have some idea of what the goal was.
The commit comment log is priceless to me, but then again, the developers I work with are pretty good about making small changes and committing often with useful and informative comments. We try to avoid large commits that change lots of files, and when we have them, we generally warn everyone in advance that its coming and to be prepared for it so as to make merging things together a little easier. If everyone knows its coming, they tend to work together to make the merge smoother and make sure things work well together.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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
I've heard git is pretty bad about disk space, but Subversion is a bit ridiculous in it's own right. With SVN you are storing the working copy twice: once for the files you will work on, and again as a backup copy so svn can do diffs.
In mercurial the repository is heavily compressed and revisions are stored as diffs (with occasional full copies) so this is a non-issue if you don't have a lot of binary data. If you're going to use that much disk space with svn, you may as well go with mercurial and have the entire repository history while you're at it.
You can synchronize on a central repository using git, mercurial or bazaar. The difference is that you have the choice of when to push your changes upstream, and you have the option to continue working and performing commits locally when you are offline.
This is all possible with distributed repositories too.
You don't use branching that much and can safely ignore the dumbest decision ever on the part of the subversion developers
I'm not sure what the "dumbest decision" you're referring to is. But I don't blame you if you don't use branching with CVS or SVN--branching is easy, but merging branches is horrid. The is due mainly to the fact that neither CVS nor SVN knows when a particular commit represents a merge from another branch of development. So you have to either merge from the branch point, or research the commit history to determine when the last time the two branches were merged--otherwise you'll have a major mess on your hands trying to merge two branches with many duplicate changes.
With a distributed VCS this is not a problem. git, mercurial and bazaar all keep track of how you merge different changesets together so that a merge only as complicated as the actual changes make it, not how complicated your VCS tool makes it.
For example, let's say you release version 3.0 of your software. You tag the changeset as "v3.0" and continue on work for 3.1.
Now suppose that a week later, a security flaw is discovered which must be patched immediately. You update your working copy to the "v3.0" tag, and start a branch "3.0_maintenance". You make the changes and commit them to the 3.0_maintenance branch.
You want your ongoing development on 3.1 to include the bug fix you just committed to 3.0, so you switch back to the default branch, merge the changes from 3.0_maintenance, and commit.
Later, when another bug is discovered in 3.0, this same process will suffice to patch the 3.0_maintenance branch and to merge the change back into the default branch.
Mercurial (or git, or bazaar) kept track of not only the branch points but the merge points for you, which makes merging simple like it should be.
Contrast this with CVS or SVN where you have to track dow
Retch.
Get your own free personal location tracker
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 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.
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.
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 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.
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
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.
An IDE would have caught that typo.
Switch back to Slashdot's D1 system.
... what's your point?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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