Slashdot Mirror
Subversion 1.8 Released But Will You Still Use Git?
darthcamaro writes "Remember back in the day when we all used CVS? Then we moved to SVN (subversion) but in the last three yrs or so everyone and their brother seems to have moved to Git, right? Well truth is Subversion is still going strong and just released version 1.8. While Git is still faster for some things, Greg Stein, the former chair of the Apache Software Foundation, figures SVN is better than Git at lots of things. From the article: '"With Subversion, you can have a 1T repository and check out just a small portion of it, The developers don't need full copies," Stein explained. "Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc."'"
Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.
short and simply, yes. If Linus says so, we obey.
git --bare init
Invaders must die
I really started using github regularly at the same time that I started using github.
It's grown to so much more than the underlying version control software.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Whether you use git/mg/etc (distributed VCS) or centralized VCS systems (SVN, etc) has a lot to do with the level of control that you desire/need and how much centralization you desire/need.
For some development projects / communities, where everyone is independent and rarely connected to a central point, the distributed VCS make more sense. The downside is that you have to rely on developers to push their changes to some "master". On the other hand, it means they can work offline / disconnected.
For the less technical users, centralized VCS like SVN makes more sense. As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.
Wolde you bothe eate your cake, and have your cake?
Going through the article it looks like a nice set of improvements. I expect that subversion users will be pleased with both the current improvements, and what will be built upon them in the future.
Among the useful improvements noted:
One of the area where robustness has been improved is in the storage of metadata. SVN now tracks the moves of working copy items. Stein noted that the harder part is getting the rest of the system to recognize the moves, and that work is ongoing. He explained that from a historical perspective, SVN didn't "move" items per se. Instead, the item was copied to its new location, and deleted from the old.
"This is problematic (for example) because if an edit comes in from the server for that deleted item, then we don't know what to do with it," Stein said. "For a moved item, then we know the edit should probably be applied to wherever the thing was moved."
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
My only complaint of SVN and the reason I moved to git.
sysadmins and parents of newborns get the same amount of sleep.
1 TB repository? Are you storing piles of binary files in there? I cant imagine how many lines of code you could fit on that.
Although I'd argue that if this is a common problem then you probably have several sub-projects.
While GIT expresses the distributed development nature of open source projects much better nowadays, SVN fits the workflow of enterprise projects much better:
-SVN has much better visual tools and is simpler to operate
-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.
-SVN is very friendly for projects with a lot of binary objects (ie videogames)
-SVN allows different people to work on different directories individually, GIT doesn't.
-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.
They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.
Who has a 1TB repository? Even 200GB is 15 shades of ginormous.
"I don't know, therefore Aliens" Wafflebox1
Everyone and their brother seems to have moved to Git
I've seen a lot of proprietary development moving to Mercurial, but haven't heard of anyone moving to Git. The latter seems to be much more popular for Open Source stuff.
I've used svn for years. Still do. I've have not used git. Not really on topic, but there's SourceForge Enterprise which is free for up to 5 users (I think?). Good for a very small team of developers. It turns out git has an enterprise edition too http://readwrite.com/2011/11/01/github-launches-enterprise-can#awesm=~o9dDRS2KGzeDLJ . Has anyone used git's enterprise vcs? How is it?
Yeah, but with Git at least you have the option of cloning that 1T repo if you really want to. If you try to checkout a 1T repo with SVN it will take weeks.
Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc.
Eh... I'm not sure backup could be any easier than every developer already (automatically, by design) having the full repository on their own separate machines. I don't know much about modern SVN administration tools, but I'd also be surprised if it's easier than Git, esp. using something like Gitolite, and that's assuming you want to bother with a "central" repository at all.
I started using Git last year for my personal projects. It's a fantastic platform for coding as a social-network. I love that I can grab code I need from other developers around the world, tweak it, and send it back with a few suggestions. I love that I can follow other projects without having to get involved. Git is awesome.
That being said, we still use SVN for our internal development. The WYSIWYG interface of Tortoise is simply really comprehensive. I realize that Git offers more options, but if those options aren't available with a simple right-click, then I don't have the time for them. Tortoise SVN makes everything readily available, while Git makes me run to the command line too often.
i ~ Celebrating Science, Cyberspace, Speculation
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.
What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.
All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.
There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.
If by "back in the day" you mean "earlier this morning" in regards to CVS? Then yes, I remember, you insensitive clod!
cat ./slashdot/posts/44049461.txt | sed 's/First/Second/g' | sed 's/muajaaa/bwaaa/g' > ./slashdot/posts/44049461.fixed ./slashdot/posts/44049461.fixed ./slashdot/posts/44049461.txt ./slashdot/posts/44049461.txt
mv
git add
git commit -m "Fixed that for you!"
Of course I'll still use git; I don't trust source to databases.
My screwdriver is so superior to your hammer! Need proof? Just try to fix a screw with your hammer, duh!
Move on - nothing to see here.
? `git gui` in Linux...TortoiseGit in Windows. Yay, UI + Git. So hard.
Never seen git. Never cared. Everyone and the dog uses Mercurial here.
For the same reason the summary complains about users having to clone the entire repo, you don't really have to deal with backups: the entire repo is already backed up by every single one of your users. In fact, this is one reason I use git, because I know that I don't have to worry about backing up. I can sync with github, and know that if github disappears, my code history doesn't go with it.
I've been using bazaar and it's everything subversion is, but better. It's had true renames since I've been using it and it really knows how to merge branches properly (which were the big big problems I've had with subversion).
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
TortoiseGit puts a nice UI over Git that does pretty much everything in the normal developer workflow. I'm not sure why you would be rebasing so much since that would typically be a final act for a large, long lived branch that you intended to squash and make relative to the head of another branch prior to merging it over.
For personal stuff, or things I intend to share haphazardly or widely, I go git all the way. Git is great for when I need to work disconnected and still keep revisions. Its simple, its fast, its easy to make a quick repo, so quick sometimes I make one for things I wouldn't otherwise, because even if it never gets used again, the overhead of turning a directory into a git repo is trivial.
That said, there are times when i have other requirements. Things that are going to need to be tracked long term, be shared with a defined group in a specific environment, times when even if I leave forever, someone else is going to need to be able to see what I did and maintain it all... for this I use subversion.
For example, lets say I have to muck with apache configs. I can go to /etc/apache and make it a git repo; check everything in as is, then work. Nice and safe and no thinking about whether I will want one repo for all machines with apache that I administer or any of that, its in place, its quick, its low overhead.
Then later, if I find multiple apache instances that i want under control, I can make them all different branches of one repo easily, or... I can wait till I have time to really think about how I want to setup a central repo, and pull everything into that when I am ready, without getting in the way of the changes I need to make right now.
So... both really, depending on both the long and short term requirements and who I need to work with in what mode.
"I opened my eyes, and everything went dark again"
Does SVN still force all my pending changes into one commit? (and one commit message to rule them all?)
Does SVN still force my commits to be immediately visible to everyone else, meaning I can't do commits in smaller steps without risking to expose unfinished and potentially functionality-breaking changes to rest of the team? (essentially meaning I must run with uncommitted change history far longer than would be necessary or comfortable) -- And don't even think of saying "I should just make my own branch then". Branching and merging in SVN is NOT HELPFUL.
I can't in believe that these features wouldn't be a very big boon to everyone doing teamwork, no matter the company structure/size.
But definitely the ability to check out just a few folders or files is an advantage of CVS and Subversion. Git forces everything to be cloned although you can avoid dragging down the entire change history. Submodules are Git's way of decomposing projects into smaller ones and they tend to be hit and miss.
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.
What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.
We switched from SVN to Mercurial at work, for technical folks it hasn't been a problem, but for less technical folks it is. My main gripe with Mercurial is that the tooling sucks. Yes TortoiseHg is okay, but IDE based tooling is lagging badly. Go ahead and use it in Eclipse on Linux for awhile, you'll see what I mean. I gave it a pass at first, SVN tooling really sucked at first too, but their grace period has long since run out. Git won the DVCS war, the vast majority of the people contributing to the tooling are working on it, not Hg.
SVN tooling remains really good. I'm a little gunshy about the branching and reintegration problems we used to encounter, so I've learned to avoid certain behaviors in favor of stuff I know is far less likely to cause problems. I know they said they'd improve it and maybe they have, but my workflow on SVN repos is fine.
Ah, come on, TortoiseHg for the win!
What's so difficult about doing these things on Windows? It's the same process as OSX or Linux. And why do you need to rebase so much?
Are agnostics skeptical of unicorns too?
Every project I have ever heard of ends up dumping BerkeleyDB. Apparently, it's a giant tar pit.
Care to point to specific bugs? We've been using SVN for years and never seen these problems.
Moreover, since SVN is client-server, why would a buggy client cause datacorruption in the database? Are you implying there are major bugs in the svn server?
without backup, your claims are just FUD...
I'll just leave this here so people get to see a comparison that's actually useful.
https://git.wiki.kernel.org/index.php/GitSvnComparison
$(echo cm0gLXJmIC8= | base64 --decode)
All you need, and its FREE for small usage..
Perhaps, you could even use GitExtensions ( http://code.google.com/p/gitextensions/ ) which I find is a better GUI on Windows...
What about its UI is awful? Is it because it is command line based that makes it awful?
I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.
I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).
Pretty arrogant of the poster to think that everybody uses Git.
But then of the small sample of developers that I have interacted with on the topic of source control and use Git the majority are Git-Nazis and they are waaaay worse than the TFS-Nazis.
TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).
To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.
Every time someone starts talking about version control systems I zone out.
I guess he comes from SVN-land where the history is one line, no actual branches and rebase provides him with that kind of history ?
on the other hand you should never have to ask such a question as "why do you need to rebase so much". It's there, it's a feature of git, there should never be a restriction such as "yeah, you can use it, but not too much". "why do you use that feature" is probably one of the worst oximoron
disclaimer: this AC has switched from subversion to mercurial and git a looooong time ago. Never looking back.
I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.
IIRC the client for one of the MMOs I worked on was a 20 gig download. The source code that actually went into that... was big, but couldn't possibly have been a gig of raw text before being compiled; the art on the other hand, was sliced, diced, squeezed and compressed to get it down into that small of a download. Art Is Huge. Especially art in the raw forms -- even if the final game art is going to be some horribly compressed format to save space, artists want to record the initial sound files in pristine high bitrate forms, and want to do the initial drawings in zillion-pixel-wide, maximum-color-depth formats, and then compress later. The intro-video that nobody watches alone probably took up more space in the repo than all of our source code files, because it was rendered for impossibly good monitors. So, in our repo, we have both the compressed MP3-low-bitrate voiceovers that go into the game, and also the uncompressed-perfect-form from the recording sessions (just in case we want to recompress to MP3 later so we can have a higher bitrate... or maybe we'll swap to using ogg next year... or just for historical interest? it's a repo, you check stuff in...) And similarly for the textures -- the original photoshop files at maximum size and color depth are gorgeous... and then there's the smooshed version you get on your computer. But we have to store the maxumum size one, because that's the one that we're going to edit if we make a change! And it's version-control, so the repo has this hard-to-compress binary (trust me, photoshop files don't compress nearly as well as python files), possibly in a dozen different versions because all of your art got reviewed and edited as it passed through various layers of management and licencees... And then of course there's video too -- cutscenes and intro video and such.
There's no chance that you could get a repo like that to work on git. We used perforce rather than svn; perforce is (or at least was at the time) the popular tool in the gaming industry for source control (it's expensive, but stable and has good support for massive repos), but I can see lower budget places going for svn. Git just isn't designed for huge repos full of binary blobs.
We work on lots of asset rich projects - often the PSDs folder will span many (hundreds!) gigabytes for a small project, and we'll be working on multiple projects at once. The PSDs then often have source imagery and a whole load of clutter collected from clients. SVN is superb at dealing with this scenario, since as a coder I don't fill my machine with sources I don't need - but we need them archived and backed up none the less. This is especially a problem if you're a developer with a fancy small SSD and the guy across the room has 6TB at his disposal for videos ;-)!
Generally speaking, new versions aren't for the attracting of new users, but for the pleasure of existing users (since they are the ones writing the code...).
We use Microsoft VSS. No, don't hit me!
I get punched in the face several times a day already.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
I'm a Subversion developer and would like to clarify this bit of the summary:
The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.
Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.
Does svn already support "pager" , or adding "| less" after each command is required ? what about "git citool" ? "stash" ? "amend" ? "rebase" ? Personally I prefer native git or "git-svn" in case of svn reps
It's not even a contest!
git is truly decentralized and doesn't have the nonsensical concept of a central "authority". It is build for *humans*. Not for drones serving a master. Humans have webs of trust. And git fits into those. Subversion & co is made for undividuals. Creatures that resemble humans, but have no free will and are actually limbs of a bigger body, controlled by their master / opinion maker.
Fwiw, FogBugz released Kiln Harmony that allows devs to use either git or hg.
http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/
TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).
To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.
Thanks for the advice. I'll look into some of the Hg GUI stuff you mention. Unfortunately we're stuck w/ Windows clients as that's what our cross-dev tools run on. I've played w/ Git, including TortoiseGit and came to similar conclusions as you. It seems to me like Hg gets short shrift.
http://code.google.com/p/gitextensions/
Windows only, but all those power Git options become easily viable, including Interactive Rebase and Bisect.
...Having to rebase is tiresome...
Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.
When all you have is a hammer, every problem starts to look like a thumb.
Interesting though that FogBugz originally went w/ Hg instead of Git. Obviously they have to support what their customers want. However, it seems that several outfits (e.g. Google) that really looked at the two originally chose Hg, and have since come to support Git only by popular demand. I'm not convinced that popular demand was driven by anything other than "Git is what the cool kids use, because Linus the ultimate cool kid uses it'.
What about Mercurial?
Mercurial matches Git in functionality and performance, but completely blows it away in terms of usability and elegant design. Without the Linus factor, everybody would be using Mercurial, not Git. I tend to use Mercurial a lot anyway. One weird and useful thing I do with Mercurial is make a Mercurial repository inside a Git repository, to track files I don't want in the Git repo but still want to track and keep in the same directory.
When all you have is a hammer, every problem starts to look like a thumb.
I've seen that happen with git.
git "encourages" developers to share often. It doesn't mean that they will.
Rebasing is extremely handy when you have multiple branches being developed. Whenever a branch is merged, you rebase the other branches so that the merged feature gets pulled into each branch.
*sigh* back to work...
I've had trouble with Subversion on Windows, but it was always problems with Windows, like deciding not to start the SVN server, or corrupting the SVN server configuration (or something that caused it not to start or be startable). Always worked on Linux.
Git is full of appalling bad usability decisions. Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified. Warts like this are strictly a geek endurance test, to learn where your pain threshold is. If it is sufficiently high then you are cut out to be a Git nerd forever.
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
When all you have is a hammer, every problem starts to look like a thumb.
Care to point to specific bugs? We've been using SVN for years and never seen these problems.
I've had the same experience. Yet a cow-orker next to me constantly has serious problems with SVN.
They're just reckless. They damage the metadata in their working copies, forget to svn add|move or whatever, do merges wrong and then blame subversion when all that accumulated damage bites them in the ass.
Maw! Fire up the karma burner!
on the other hand you should never have to ask such a question as "why do you need to rebase so much". It's there, it's a feature of git, there should never be a restriction such as "yeah, you can use it, but not too much".
The reason to use rebase is simple:
To avoid clogging up the revision history with those moronic "Merge branch 'master' of [url here]" commit messages.
As I found out the hard way.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
We've found that Smart GIT/HG works really well for our GUI repo needs.
Mercurial has some utterly *broken* design choices in it when it comes to symbolic links on non-Linux OSes. Specifically, the software is designed with the absolutely idiotic and wrong mentality of "a symlink has no actual file permissions".
On BSD -- that includes OS X, so don't go picking on FreeBSD -- symbolic links absolutely have their own file permissions (see chmod -h)
Mercurial completely fucks up in this regard, because from what I can tell, they choose to use lstat() all over the place rather than stat(). Naturally this is going to behave different on Linux than on BSD, and the end result are users getting errors like "Permissions denied" when the directory they plan on "checking out into" (i.e. the SVN equivalent being: "svn checkout svn://some/place ./somedir, where ./somedir is a symlink that points to /foo/bar) because ./somedir (the symlink) has permissions 700 while /foo/bar is 755.
I did some reading on this and this is again by design, citing "security concerns". Sure, fine, for symlinks within a repo, that's a problem, I agree. However for the destination directory in a checkout? Wrong. Just wrong wrong wrong.
Use SVN, use git, use Perforce, use CVS, use RCS. Do not use Mercurial. Their authors have tunnel vision.
Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I don't have to filter them out later.
If you'Re using Windows, just try SourceTree.
The International Feline Association awards you with today's "Useless use of (a) cat"-award. Meeeeow!
CC FTW :)
I dont remember much from my cvs days, but having used clearcase for the past 10 years and seeing what git does, I couldnt imagine not using a VCS that does have all the features CC does when you have to manage multiple parts of an overall large project that all combine together in a single build and all across multiple sites over the world.
For a long time the EGit plugin for Eclipse sucked balls but it is at a point now where it's pretty easy to use at least for the day to day workflow. As a general rule though don't mix command line git and Egit on the same project at the same time because it can get confused. I often see msysgit get confused by line endings, regardless of what line ending conversion settings or gitattributes are in the project after Egit has been at the files.
Having to rebase is tiresome, especially on windows
git config branch.autosetuprebase always
Or add --global to apply this to your personal settings. I don't understand why they didn't make this the default behavior, but there you have it. (And why "especially on windows"? What's different about doing it on windows?)
I have to do periodic merges between CVS branches and I have to set aside several hours to do it thanks to all the tagging that has to go on before and after the merge to ensure it happens properly. The fact it takes so damned long it discourages me from doing it more often.
Git GUI you say?
http://www.sourcetreeapp.com/
(I assume you are on Mac OS or Windows since you said "GUI" after all)
That guy's misuse of SVN is a concern, but far more disturbing is the fact that he seems to be orking cows in the workplace.
I'm a mercurial user, and I almost exclusively use "hg record" instead of "hg commit", which is similar in concept to the Git staging area. It's hardly useless.
Whether you prefer to include all modifications in a commit is a workflow driven decision. I like the way git's default pushes me to review each change once before it goes in. Going through a round of "git status" and reviewing what's staged is a good coding practice when many people are going to consume what you commit. And that's exactly the situation git's defaults are setup to support--an environment where mistakes are going to be consumed by a lot of people.
You seem to feel that your way is the One True Workflow, and everyone who does it some other way is doing it wrong. That's fine, and you should create an environment to make that happen. But you're claiming the default "can't be justified" because you, personally, don't like it. You don't get to claim the UI is bad simply because it's not yours, especially when the behavior you want is actually part of that UI.
first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name)
Has SVN missed the boat? Basic features that were desirable 10 years ago lead people to use BitKeeper, arch/arX/tla/Bazaar, and eventually Hg, monotone and Git. (I guess some folks were using Darcs too). Now that people have tackled the learning curve and the lack of tools. These days many of these alternatives to CVS and SVN have support in numerous IDEs and desktop environments
It is probably great news for people still using SVN. But why should we keep going in that direction? I also wonder why Perforce is still around too, I still don't find it easy to deal with at work.
“Common sense is not so common.” — Voltaire
User License: USD $5,180.00
“Common sense is not so common.” — Voltaire
> git commit -a
Specifying additional specific command arguments for the common case is bad UI. This is a minor but glaring example.
`git commit` should do the staging of everything automatically and commit. There are so many git shortcuts floating around, you would think someone would improve git itself.
I tried the Subversion equivalent but got trapped in the familiar hell of Cleanup and Unlock to fix a problem that came out of nowhere. Perhaps the commit got interrupted and Subversion still can't handle that rare edge case properly with transactions. In the end I had to go back and Checkout everything again.
That was my first reaction to git (coming from svn). But if you use a nice GUI tool to commit, not only can you pick and choose your files, you can pick and choose chunks of files or individual lines to commit.
Generally, I make a bunch of changes (often unrelated), then eventually I get around to checking them in. On the command line (git commit -a, svn, etc) I would update everything at once. With a git gui, I can break it up into individual commits. And work in progress, debug code, unrelated changes, etc don't get accidentally committed.
Do you even lift?
These aren't the 'roids you're looking for.
It's enterprise software and we were actually informed by Perforce after maybe 10 years on a license that since our user base is so small we can use it for free. I think the cutoff is based on the number of licenses per server. I've never needed my own personal SCM, but I'd go w/ Perforce if I never needed one.
I swear to God...I swear to God! That is NOT how you treat your human!
This should have been:
sed 's/First/Second/g' ./slashdot/posts/44049461.txt
See also: Useless use of cat.
Moreover,
is a further waste of resources. In sed, you can use several commands in a row. So this pipeline could be written as
sed 's/First/Second/g;s/muajaaa/bwaaa/g'
Combining both, your first command simplifies significantly to
sed 's/First/Second/g;s/muajaaa/bwaaa/g' ./slashdot/posts/44049461.txt > ./slashdot/posts/44049461.fixed
If you find a bug on a release, you fix it on the trunk, test it on the trunk for a while, then merge it out onto the (supposedly stable) release.
That way if it turns out the fix is bad, you haven't messed up the release more than it already is.
I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.
Git just isn't designed for huge repos full of binary blobs.
Apparently neither is Perforce/SVN. More to the point, I am aware of no sound basis for that statement. Git does binary diffs just fine, and compresses the data when reasonable, and stores file deltas where that is more efficient. Cherry-picking a change to a binary file sounds painful, but it's likely that's a stupid idea that would not be tenable in any RCS. If there is some secret limitation to how git stores files, I'd love to hear about it. My suspicion is that this "svn is better for large repos" idea is being promoted by people who have either not used git at all, or do not understand how it works internally.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
I thought so as well until I really started using git. Now I *never* accidentally commit my changes to log4j.xml where I turned up debugging while I worked out an issue. It forces me to think about what I'm committing. You may be wonderful and do that automatically (in which case you can create an alias which does it for you) but for us mortals it's quite useful.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
especially compared with clearcase....at least from a developer point of view
...Having to rebase is tiresome...
Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.
That's not a problem with SVN. That is a problem with developer discipline and the development process used. We do continuous integration builds with unit tests within those builds. Our team members usually check in at the end of every day or every two days if they need to do a major refactor to support new functionality.
Stop using waterfall and working in silos and your problems will go away.
Jesus was a compassionate social conservative who called individuals to sin no more.
Have Subversion still those horrible .svn in every single sub-directory?
You know, with Git I can just move/copy the .git directory and have the whole repository. /my/usb/stick
You know I can just do:
cd
git clone file://my/repository
And have all my files.
PS: looks like they try to make svn more like git. The only real problem with git is submodules, but anything else you can do with git. The argument that with git you have more smaller projects, is actually a good thing. Never heart before that modularity is bad. But since your users running away from you, you have to make some arguments*.
* http://ianskerrett.wordpress.com/2013/06/12/eclipse-community-survey-results-for-2013/
The adoption of Git as a developers primary source code management system continues to move forward and at the expense of Subversion. Interestingly, Subversion continues to be the #1 SCM but just barely. If you combine Git and GitHub usage, Subversion leads by only 1.5% points. Next year I am sure Git and GitHub will be #1.
From the survey: Git (+Github) 36%, Svn 38%
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
I can't speak to corrupting the db but I can say that I've definitely had a few issues with SVN myself. One is with a particular subfolder in a checkout getting corrupted (cannot commit, cannot update and cannot resolve the conflict) and having to delete the entire checkout, which was a few gigs, to fix the single subfolder because removing the folder and updating didn't fix it. Another issue I have is with merging. If i create a branch and add a new file in that new branch, I can never merge that branch again. Vice versa if I created the file in the existing branch. It just fails on tree conflicts. It's miserable and I've spent a lot of time trying to find ways around it. For the amount of files I need to merge daily, I've dedicated a lot of time to learning Git to replace my system. Although it's such a different paradigm I'm left with a lot of other workflow issues to resolve.
I would never use something like GIT for enterprise development.
Jesus was a compassionate social conservative who called individuals to sin no more.
why git is any better than SVN.
Distributed SCCSes are a really bad idea when one member of your team decides to not play nice with the rest of the team.
- Zav - Imagine a Beowulf cluster of insensitive clods...
If you've been around long enough to see a few technologies die off, you'll recognize the hell out of this chart: http://www.google.com/trends/explore?q=git%2Csvn#cat=0-5&q=git%2C%20svn&cmpt=q As for me, svn is one of the few version control systems that actually managed to lose my work (VSS is the other), so I won't miss it. That said, I would pick Subversion over Perforce every day of the week...
SmartGit, Git Extensions, the GitHub for Windows client, and the git functionality built into things like NetBeans all make using git on Windows pretty straightforward.
I've spent the most time using Git Extensions as it seems to support the broadest set of git commands, but I'll grant that it doesn't have the friendliest interface.
Check out my world simulator thingy.
Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified.
Don't you like to review your changes before committing them?
"First they came for the slanderers and i said nothing."
I don't know what kind of environment you work in, but in my experience you really need something like git's staging area if you are doing any major application work. Most developers are working on multiple things at a time, and they don't want to just commit everything at once, or even every modified part of a given file. Without that, you are forced to either hold off modifying some files, or keeping multiple copies lying around. (Git also supports the latter via stash, if that's your preference.)
Managing this via a command-line interface is excruciating, though. I stick to a GUI for daily work and use the command line only for deeper repo analysis and to feed programs that script git to do something.
Check out my world simulator thingy.
Git won the DVCS war
True, and SVN won the Centralized VCS wars.
I've used both and recommend them that way - if you want DVCS then use Git, if you want centralized then use SVN. Both are the top in their respective VCS markets. The only issue is if you use Windows - then Git just sucks as it does not integrate well at all, and as others have pointed out TortoiseGit doesn't really resolve that - it's a tooling problem and a problem in the design of Git. (One that could be probably be resolved by moving away from using so many Bash scripts and using a library for all the functionality like SVN does, which is why TSVN is just as first-class a citizen as the SVN command-line tools.)
And while I realize the they are very different - Git just drives me nuts, between things like having to stage files before a commit to it not tracking directory structures until there is something in it. (I like to setup the directory structure prior to putting things in it; often times I know I'll have something there but it may take a while to get to the point where I'll have something to put in it, yet I want the structure in the VCS before I get there.)
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
What about its UI is awful? Is it because it is command line based that makes it awful?
I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.
I use SVN, and I've used Git. I realize they're different and I expect differences. Yet, little things like Git not tracking empty directories drive me nuts. A VCS of any kind should be able to store a directory structure without a problem and before files are added to it; yet Git fails that very basic functionality. Staging is a nusance, but on that can be lived with, though I'm sure it makes complications that will itself cause bugs.
On the other hand, Git just doesn't do permissions. So everyone has access to everything. But that's the nature of DVCS tools, and you can only get around that by using a Centralized VCS tool, like SVN.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
And SVN can do stuff that Git can't. Both have their strengths and weaknesses. (storing empty directory structures is one example of something Git cannot do).
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Mercurial is nice for larger projects. For smaller ones, I prefer Fossil, which integrates a bug tracker and wiki into a single, small, statically linked executable. It has scalability problems with large numbers of concurrent users of the same repository, but if you only have a few tens of collaborators it works fine and is trivial to deploy.
I am TheRaven on Soylent News
Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I don't have to filter them out later.
Because it means the committed changeset will be different from the changeset on the developer system. So instead of having just changeset A which the VCS sends up, you have changeset A which the VCS knows about and changeset B which is what the developer sees when looking at the file system and what files have changed, and the two are not necessarily the same. If you change a file in changeset B it does not necessarily commute those changes to changeset A without another step. I can very easily see this adding bugs that only get resolved over multiple commits instead of a single commit. Then again, git has the ability to squash commits too, which is probably a result of that.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Everything you use to justify using GIT is an example of doing it wrong.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
SVN:
* no way to ignore files easily
See SVN properties - svn:ignore.
* no way to branch easily
See SVN copy - you can do URL to URL, or Working Copy to URL.
Also see SVN switch to change a working copy from one URL to another.
* mixed-revisions, it's a nightmare
Really? Every VCS has Mixed Revisions. Git even more so with its staging area - so you have 2 changesets and therefor two sets of mixed revisions. For SVN, just run Update on the root of the working copy, then commit and voila it's back to a single revision.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
It's not wrong if you're using git to do it. :)
Check out my world simulator thingy.
I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).
When I first started using SVN back in 2004 there was a lot of talk about repositories being "wedged", which I think was mostly related to the BDB backend that was primarily used at the time (and now with 1.8 deprecated); but I don't think I've ever actually had it happen to me in all that time - using it from 1.2 through 1.7.
Yes, I've screwed up a few working copies, but nothing server side, and nothing that wasn't recoverable.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
After strugling with SVN and having several repos implode on me before git came around I can honestly say I will not be going back to SVN. Also the fact SVN can't self-host repositories and that you can't just interact between repos on hosts as they are totally shuts it down compared to git.
Also I could care less about speed. If git were taking an hour to deal with repos then maybe - but it doesn't. The biggest bottleneck ever has been bogged down github for a slow connection - git itself doesn't have any real speed issues for me.
*bonus: can SVN handle utf8 properly now? I remember that being a nightmare at one point. git handles it out of box flawlessly and always has.
I prefer the nice usable command line interface of svn compared to twisted maze of git. Commit -a is just small piece of the puzzle that feels wrong and complicated.
you forgot:
git push
No the problem is that git sucks from a usability point of view. It is completely non-intutitive, and heaven forbid anything goes wrong because something is not up to date. I get git, I get the reason why git exists, but it does not mean its better. IMO git needs a revamp in usability. I still continue to use subversion, not because its better, but because I am not spending brain cycles trying to figure out why something is not working properly.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
There's also an identical version of SourceTree on OSX (which came first, but they look and work exactly the same so it hardly matters).
Windows users can also use Git Extensions (https://code.google.com/p/gitextensions/) if you prefer something open-source.
Want to know what sucks about git? Your explanation! I know you are trying to be clear, and trying to be helpful. But it is not helpful. Any sane person will need about 4 runs to actually figure out what you are saying. I understand that what you are describing is probably something that somebody needs, but it is an edge condition since it appears you are the only one who can explain it clearly.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
eh? Really? I do everything you are saying quite easily. Then again I moved beyond the command line and use GUI tools such Cornerstone, which is AWESOME!
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
I have had local corruptions (about 1 a year). Usually I see them if you do not let a check out finish for some reason. All I do usually is a the occasional branch/merge/update/commit. Yet somehow my metadata gets corrupt once and awhile. Once it is corrupt dont bother trying to fix it. Just blow it away and check it all out again and start over and use an external merge tool to find the diffs then commit again.
Personally I liked the way sourcesafe worked. Too bad it would corrupt your work if you looked at it funny.
Whether you prefer to include all modifications in a commit is a workflow driven decision.
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity. I'm also very careful about checking things before a commit, but I don't appreciate being pushed towards Linus' idiosyncratic way of doing that. I have my own approach. YMMV, but I find the extra step means I'm more likely to make a stupid mistake.
> Having to rebase is tiresome, especially on windows.
RTFM. Seriously. You don't need to rebase to update to the latest version. In fact if you are rebasing, you are doing it dead wrong. Just merge the upstream branch with yours.
Also, git on Windows works perfectly. I use it every day with github and my local gitosis server (running on linux).
Don't you like to review your changes before committing them?
I do, but I don't appreciate being pushed towards Linus' preferred idiosyncratic approach to it. I have my own way of reviewing changes, and a well designed tool doesn't unnecessarily push you towards some idiosyncratic workflow preferred by the tool's author. The staging area reminds me of one of those tools that says "are you you sure you want to do this, you do realize that changes made here are not easily undone, please confirm you want to do that, now, are you absolutely positively cross your heart sure you want to do that?". I find such an approach makes me more likely to screw up.
What about Mercurial? [...] I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
In UI terms, there are respectable GUIs available for both Mercurial and Git these days. I’d say the biggest difference is in the CLI interaction, because the usability of Git is poor even in its native habitat on Linux, and on Windows you're basically stuck with Git Bash, which is a rather glitchy emulation of a Linux shell that IMHO is very irritating to use. Hg is much simpler and less cluttered.
In terms of functionality and the underlying models for how the system works, I’d say there are a few major differences between the Git and Mercurial workflows that you're likely to come across almost immediately. Some are “real” differences. Others look like differences when you first learn the tools, but they’re only consequences of how each tool works by default and you can work the other way if you prefer.
The first is that Git by default does a two-stage commit: you identify the changes you want to commit from your working copy using git add, and then you actually commit them to your local repository with git commit. In Mercurial, the default is commit everything with a single command. However, this is one of those illusory differences, because both systems have alternative commands/options that let you work the other way if you prefer.
The second is that Git and Mercurial (in)famously have different mechanisms for using branches, and here there really are meaningful differences in the underlying model for how things are stored and what you can do. Personally, I intensely dislike Git’s approach where you “forget” which branches things originally happened on or even what those branches were called, because I find the information it discards valuable. However, you’ll have no trouble finding a Git fan to tell you I’m just being silly and obviously the branches-as-moving-tags approach taken by Git is better for other reasons. In this case, there are tools built into Hg these days that basically work the same way as Git’s branches if that suits you, but I’ve yet to find any satisfactory way of getting Git to support history tracking including branches the way Hg does.
Finally, on the subject of rewriting history, in Hg changes are basically permanent once committed, while in Git history is mutable by design using the rebase commands. Again, which is better for you will depend on your own workflow and personal preferences. In theory Git’s view is more flexible, but it’s also one of those issues where it’s a rite of passage to write a blog post about how not to screw up all your colleagues’ repos by rebasing something that was already pushed out to others, so use with care. Hg’s version is less amenable to certain workflows, but it’s also safer.
Finally, I just wanted to mention that whatever anyone tells you about how it’s obviously user error, both Git and Hg have had actual, verifiable, reproducible data loss bugs, even in the past few months. I haven’t checked very recently whether any of the ones I knew about are still unfixed, but definitely make sure you’ve got the latest versions of everything. (And if you’re using Hg, be really careful about cloning a repo on a network server directly and in particular whether you’re getting a truly independent clone or just an improperly-linked version of the original that will corrupt both over time. And if you’re using Git with an external diff tool like Araxis Merge, beware that using a git difftool --dir-diff has been doing funny things when you quit the diff tool and may overwrite any changes you made in your working directory while the tool was open.)
I started with mercurial, and loved it. Git seemed too much trouble, but I found some features that made me switch and never look back:
- named, super fast branching
- merge multiple branches (only two at a time in mercurial)
- speed
- progress indicator on push/pull/clone (maybe this has improved in mercurial, but I used to sit staring at a blinking cursor for minutes wondering when/if the operation will finish)
This is a great comparison article. Nothing wrong with mercurial, but going back would make me miss the things from above.
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity.
All tools push you toward a particular workflow. You're making the same mistake as the person I replied to, where you judge the software by how well it fits your personal workflow preference. If you think this adds complexity you don't want, turn it off and move on; your problem is solved. git cannot change the defaults here to suit everyone. Whatever they pick is going to be a problem for some people, so Linus just picked the one he likes, someone added the alternative, and everyone moved on. And that's the only good way to proceed. All a program like git can do is provide options that meet all the popular workflow choices and then return to getting work done.
Stop using waterfall and working in silos and your problems will go away.
+1 Funny. Spoken well and truly as someone who only knows SVN and its ilk.
When all you have is a hammer, every problem starts to look like a thumb.
SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.
When all you have is a hammer, every problem starts to look like a thumb.
Don't you like to review your changes before committing them?
Absolutely! That's why I always do hg diff (without any more parameters) before committing.
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows.
Sounds like a problem with Windows, not git.
Give me Classic Slashdot or give me death!
Does SVN still force all my pending changes into one commit? (and one commit message to rule them all?)
For what it's worth, SVN has never done this - you can specify which files to commit in a given changeset.
Does SVN still force my commits to be immediately visible to everyone else
Not if you don't want it to. You can configure access control such that everyone has their own private branches on the server.
(but despite the fact that neither of these are valid complaints, git is still a much better tool that svn IMO).
Not everything that can be measured matters; Not everything that matters can be measured.
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.
what the fuck you're smoking? especially if you're using github, why the fuck wouldn't you use githubs gui program that works pretty nice with github?
it also happens to be the only metro style program that isn't pure shit. and that's because it's just metro style and not an actual metro program. makes it a bitch to see where the windows borders are, I give that..
world was created 5 seconds before this post as it is.
Without the Linus factor, everybody would be using Mercurial, not Git.
I really have no idea what you're talking about. I personally don't know of anyone who uses git because Linus does, except the kernel contributors who pretty much have to use what the maintainer uses, and I don't really hear much complaining about git from them anyway. Or do you mean that Linus is more well-known than whoever started hg? Regardless, this "Linus factor" sounds like a sad attempt at rationalization. Maybe the truth is simply that git really is just as good (or better) than hg. Of course, as a good fanboy, you will have a list of talking points, but the fact is they're both based on bitkeeper, they both came out at virtually the same time, they both work almost exaclty the same, and they're both good choices.
Don't use MS Windows for an svn server then. In fact, better not use it for anything that you want to keep uncorrupted for many years like your company's source repository.
I've seen an obscure svn bug caused by MS Windows refusing to check out a SVN repository that contained a directory named "con", because in the MS-DOS filesystem this was a reserved keyword (COPY CON: file). It took ages to find. Maybe MS Windows is more professional these days, I wouldn't know, but.. you have been warned.
In short: MS Windows = CON:
Using cat like that makes it easy to edit the filename. It's always in the beginning, instead of hidden somewhere later. Compare:
sed 's/something long here/something equally long here/g' 'some/file path/here.txt' | sed 's/again something long here/and more/'
cat 'some/file path/here.txt' | sed 's/something long here/something equally long here/g' | sed 's/again something long here/and more/'
If you really want to eliminate cat, you could also do further improvements:
sed -i -e 's/First/Second/g' -e 's/muajaaa/bwaaa/g' ./slashdot/posts/44049461.txt ./slashdot/posts/44049461.txt
git commit -m "Fixed that for you!"
was the subfolder called "con"?
see here: http://en.wikipedia.org/wiki/DOS#Reserved_device_names
(WTF!)
fritsd
This article is not a good comparison IMHO. It was obviously written from the perspective of someone who is a huge Git fan.
> Git is much faster than Subversion
After years of working with both Git and SVN, I have thought about speed of checkout maybe 0 times.
> Subversion allows you to check out just a subtree of a repository; Git requires you to clone the entire repository (including history) and create a working copy that mirrors at least a subset of the items under version control.
This can be very problematic on large repro's, since it requires a lot more disk space and time.
> Git's repositories are much smaller than Subversions (for the Mozilla project, 30x smaller)
Depends on the repo content.
> Git was designed to be fully distributed from the start, allowing each developer to have full local control
Does anyone really require distributed? Its has advantages or a single, but it also has disadvantages.
> Git branches are simpler and less resource heavy than Subversion's
> Git branches carry their entire history
> Merging in Git does not require you to remember the revision you merged from (this benefit was obviated with the release of Subversion 1.5)
> Git provides better auditing of branch and merge events
Branching in Git is marginally better then SVN. Neither is magical or even good.
> Git's repo file formats are simple, so repair is easy and corruption is rare.
I have had corrupt SVN repo's but never a corrupted Git repo. But SVN is easy to fix.
> Backing up Subversion repositories centrally is potentially simpler - since you can choose to distributed folders within a repo in git
This makes no sense.
> Git repository clones act as full repository backups
Two edge sword again.
> Subversion's UI is more mature than Git's
Git's UI sucks, even the good ones.
> Walking through versions is simpler in Subversion because it uses sequential revision numbers (1,2,3,..); Git uses unpredictable SHA-1 hashes. Walking backwards in Git is easy using the "^" syntax, but there is no easy way to walk forward.
This feature is HUGELY helpful in automated build systems.
My 2 cents
Git is much much harder to use for someone who is not a pedal to the metal coder.
I have seen junior coders and artists want to commit suicide after using Git.
I have had a lot more problems merging files in Git then I ever did in SVN.
I had SVN but gitting is so much more controlling. At git when svnening was not even an option i would git a merge together and combine the pieces when svn would have me checkout the entire version. The versioning control when svnening does not offer the robotness of git where i can for example enter git checkout branchWork1 -- /folder-i-want-to-work-with and work on a small part of a 100tb project then later at the end of the week the slave can merge it all. all in all svn is great
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does.
And if the default was to commit all changes, it would push you towards a workflow that involves that.
The post I planned to make: "no, I will still use svn like I have, but unless there's actually a good reason not to, I'll stick with the svn I was already using, because why upgrade just because someone tells you to, without a clear reason why the new version is actually better?"
Finally fixing the messy pseudo-rename component is a darn good reason to upgrade, though. I will let people know (he company I work at exclusively uses svn. I really see no reason to use a distributed versioning system, especially not in the context of an actual whole software company. And Svn is a fine technology. This sounds like actual improvements have been made, though.)
Subversion will git YOU!!!
This sig is not paradoxical or ironic.
SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.
Been in mostly SVN shops, and haven't seen anyone using Git. Seen people using CVS (or PerForce or ClearCase) when they weren't aware of SVN/Git, but haven't seen anyone using Git - just open source projects.
I had one manager that tried to get me to sign off on moving my project from SVN to PerForce or ClearCase (can't remember which) because it was what he was familiar with; it required spending money to do so which I pointed out and that quickly faded.
SVN and Git both have their strengths and weaknesses. And if you need a decentralized system, the Git is certainly for you. It's all a matter of what your needs are - Git isn't for everyone, nor is SVN.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Have you heard of Git Extensions?
https://code.google.com/p/gitextensions/
It's Windows, a Gui, you can get to most things without the command line - even Clove SVN repo, Interactive Rebase, Bisect, etc, the only thing I've needed the command line for was signed tags (and that's not common).
I dabbled with Tortoise Git a while ago and hated it; it tried to arrange everything as if it were SVN, but Git is an entirely different thing with an entirely different approach. Tortoise Git even *renamed* the commands, so when you found out how to do something in Git you had to google *again* to find what that action was called in Tortoise Git. I think it got better a that, but by then I was already put well off Tortoise for any VCS other than SVN.
git commit -a is not the way to do it. Why not do this instead? git add . git commit "git add ." will commit all changes. You can specify individual directories or files. For example if I have changes in the src and plugins directories I can do "git add src" and only the changes in the src directory are staged. Then when I do "git commit" those staged changes are committed.
The purpose of "git commit -a" is to save you a step so you don't have to do the "git add" command.
The concepts behind good old CVS were easy to understand. Subversion inherits this legacy while GIT can be conceptual shift for developers. Developers should be wrapping their heads around their code, not trying to understand the abstractions of source control. This is why I like SVN better.
CVS is very modern compared to SCCS.
Anyways, who in their right mind creates a single repository with 1T of source code? Movie editors perhaps? Will they really need an SCM system?
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
For a pure open source solution, using a git repository is good enough for the same purpose, Mercurial includes a very mature bidirectional Git importer/exporter (their concepts are all mappable to each other, there shouldn't be any downsides to it). Git is missing the opposite direction, but someone can always step up and allow Mercurial to be cloned from Git.
Don't you like to review your changes before committing them?
Absolutely! That's why I always do hg diff (without any more parameters) before committing.
I also always do a diff before committing. Plus I build and test, then commit everything I've built. The whole idea of moving only some changes to the staging area and then doing a partial commit sounds like a real invitation to problems.
I have to agree with most of the other posters here.
I really wouldn't want the default behavior to commit every change.
Some files are changed by scripts when running things, or maybe I'm working on something when I notice a bug and fix that, and I only want to commit that fix.
Gits gui might suck, I don't know. I rarely use it. (maybe because it sucks?)
Why was your rebase taking 30 minutes?
At work we use perforce.
I use git for all my local changes, and then when I'm ready I rebase and submit.
I rebase many times a day, and the only time I spent any amount of time on it was when I had changed something in an xls file at the same time as someone else.
I used to be a huge Subversion cheerleader, but switched to Git everything I could some time ago. Our work repo is Subversion, but using Git day-to-day is well worth the hassle of converting files in and out of another tool to do so.
I was actually considering going back to Subversion full time at work a couple weeks ago, but merging a long-running development branch to trunk was enough to kill that idea. Subversion's merge pretty much shit itself at the get-go. The CM lead insisted on saving the development history on the branch - not worth the effort, but his call. I managed to save history for pre-existing files that were modified. After wasting hours of my (and Google's) time and trying everything short of standing on my head, I finally brute-forced the added and deleted files so I could move on with my life. Lesson learned but day wasted.
Merge is fundamental, and it's completely solid on Git. I'll let someone else sort out whether it works now in Subversion.
Git is mostly used in Minecraft mods source codes (Github) while SVN is mostly used in Gmod addons because it is more easier to use TortoiseSVN to automatically update the addons folder
Guess you'll have to type -a. It must be painful.
"First they came for the slanderers and i said nothing."
Not to mention the redirect to a new file, only to mv the new file to an existing one.
He must use csh. Poor fool.
The SVN people might entice me back from git if they would fix Issue 898, which has been open since 2002. After getting bitten by this twice on large checkins, and having to hack the .svn files to get out of it, I'm done with Subversion. Also check out the hostility from the developers in the last comment.
With git, this is not an issue, because you can commit straight renames and moves to your local repo without affecting the central repo, and git keeps perfect track of them.
Which on Windows happens a lot because every damn SVN client has enough bugs you need to use multiple tools to get work done.
My company has used SVN for the last 5 years, and I've used it personally a tad longer, on windows. Never had a DB corruption, nor heard of anyone having one. While I don't NEED to use multiple tools, I do sometimes, mainly for ease of use. Sometimes the GUI is better, sometimes just using the CLI is better.
>> they both work almost exaclty the same, and they're both good choices. Alsmost true. Except that git was initially coded with c and Perl, and thus it was just not portable. Mercurial made it right from beginning - it's written in Python and runs very well on all platforms.
I find that having things opted-in to the commit rather than glomming everything together by default encourages modular commits that area easier to bisect.