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.
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?
Really?!
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
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
Not used SVN for a few years, but I've merged branches several times with it. Not sure what you're trying to say.
No colour or religion ever stopped the bullet from a gun
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.
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!"
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.
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.
Pfft. I've been using Github for decades before I started using github.
Yes! That is the biggest problem with Subversion, and I hope that 1.8 fixes that as promised (although they're only promising partial support right now).
At work one of my side jobs is managing the VC for our small (5 person) dev team. For a small closely knit team centralized VC is fine, but the very limited merge capabilities of svn drive me nuts. It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
I know I could overcome that problem by switching to Mercurial or Git, and I'd love to, but it's not a good idea with my team. Several of them are very good at what they do (Ph.D.'s in signal processing and detection and estimation) but have little interest in learning what is, for our purposes, the more complicated DVCS approach. Sometimes I feel lucky I got them to use VC at all, and it helps that the svn UI is a lot like the CVS that some of them already knew.
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)
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.
Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
git clone --depth 1
To add to this, last time I used SVN, it seemed to transfer each file individually which was really slow. Git compresses the files and then transfers everything
You don't need to use github to use git, bit if you really like github, you can run it on your own servers, there is an enterprise version.
Exactly. I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.
Sure, I've switched to git for my projects, but CVS is so easy to set up, centralized (it's a plus, when you need that), text files in repository and each file is versioned on it's own (it's a plus, when you need that). One great use I've found is put some software into git, manage patches with stgit, while having each individual patch in a CVS repository for patch history. I wouldn't change that for svn.
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 ;-)!
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.
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.
I'll bite. What's smug about svn? The developers make a version control system that they think is good, but they don't pretend it's The One True VCS. The users on forums, and Mercurial devs/users all likewise. By contrast Git fans, from Linus on down, act like it's the One True VCS and treat anyone who doesn't see the light as only worthy of contempt. I'm considering moving to Git or Mercurial, but I swear it'll be Mercurial just to get away from that friggin' attitude.
Documentation is also one of the strong points of SVN. The online book is fantastic.
...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.
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 don't understand however why CVS is so easily forgotten. I still use it on a daily basis.
It's forgotten only because SVN was intended to be, and is, "CVS done better". It was even created by CVS devs who wanted to start clean to overcome some of CVS's shortcomings, but intentionally and unabashedly looks, feels, and where possible, works like CVS. I've done both CVS (back in the day) and SVN repo setup, and they're both very simple. One reason I chose SVN for some in-house stuff is because the people who already knew CVS could pick it up in a heartbeat.
The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk.
I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months. If you're going to miss a merge, it's better to miss the merge back into the branch, rather than into head; because as long as it's merged into head, it'll be fixed eventually.
"First they came for the slanderers and i said nothing."
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!
If you'Re using Windows, just try SourceTree.
The International Feline Association awards you with today's "Useless use of (a) cat"-award. Meeeeow!
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.
Yo git, I github that you like to github so I github some github in your github so you can github while you github. Github?
Do you even lift?
These aren't the 'roids you're looking for.
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.
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.
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.
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.
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)
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 hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months.
I've found that a good way to prevent that from happening again is to summarily execute the offender and hang his or her corpse from the flag pole as a reminder to others.
There's also Murphy's Law corollary that says that no matter what your preferred workflow is, there will come a day when doing it differently is necessary or expedient. For example, trunk may be temporarily unstable, which means you wind up fixing the bug on the branch. Of course trunk is never supposed to be unstable, but there are a lot of things that aren't supposed to happen. A good tool shouldn't keep you from working differently when necessary (which is what at least pre-1.8 svn does, or makes it very difficult to do anyway).
If I needed github on my server, I would choose gitlab.
Really?!
He said what he said.
It's more like there is a deep hatred against Subversion. I have no idea where does it come from, but if you are old enough you'll remember that there's been a long list of revision control systems that become trendy, with fanboys claiming they were going to "destroy svn".
Arch was first, then Mercurial and now Git. The main difference is that Git became much more popular thanks to the excellent Github, but for enterprise and large projects where a centralized repo works better, SVN or Perforce are still a better solution than any of the distributed ones