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.
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
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?
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!"
All the closed source software for customers of mine (usually web apps and related services) was already on git when I took over the projects or has been migrated afterward (usually not my call). The only exception was a 1 GB svn repository of binary files that we don't really need to work much with and didn't make sense to convert. Anyway the two of us are too small a number to make a statistics. Just my two cents anecdote.
But in some environments git has become a de facto standard. Almost any Ruby gem is on github, which makes it easier to install, fork and modify. That means that many people and companies also use it for their private projects because they're accustomed to the tool. They also have desktop clients for Mac and Windows but I have no idea of what they do. I see customers hosting they remote git repositories on bitbucket too and somebody run their own server.
After years of git I can't think of using a pure centralized system anymore. Too limited.
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"
And you are complaining about "unbearably smug attitude", with your hipsterish deathgrip on CVS?
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.
just one line of code...but it's a really long line.
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.
You are confusing the repo size with the size of a checkout. With Git they are pretty much the same, but with SVN you only checkout the revision and indeed the branch that you actually need. If the repository has been well managed there may not be much in it, but as soon as someone adds binaries to the checkin the repository size is likely to explode. Here's an example: I wanted to play with a particular application environment just to get an idea what it could do. Their main 'kitchen sink' sample program at that time didn't have an up to date zip download, so the only way to get the latest version was to clone the github repository. For some reason they had included generated object files in the repository, so to get the example program it was a multi-GB cloning operation. If it had been in SVN it would have been a few MB total.
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)
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).
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.
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
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.
My 2 cents worth of data confirms your experience. My 3 last employers all moved to git from cvs or svn while i worked there. The first one was developing multi million LOC enterprisy stuff and ended up being bougth by Microsoft, which was ironic, until MS actually started supporting git themselves in tfs'12. How is that for closed sorce adoption? :)
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.
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
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.
Probably not 1TB, but the whole of the python modules maintained in the team are stored using SVN. That's quite a lot. And Git wouldn't play well with that much. That's 520 packages currently: http://qa.debian.org/developer.php?login=python-modules-team@lists.alioth.debian.org
That being said, the only reason why we still continue to run with SVN, is that nobody is willing to make the effort to switch everything to Git.
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.
Treacherous heritage?
...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...
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.
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.
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.
So we live in different caves, because I've never seen mercurial.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
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.
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.
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
Spoken like a true brainwashed robot, parroting your propaganda. Meanwhile, real people capable of thinking for themselves understand the concept of using different tools in different situations, and know that sometimes it's better to be centralized, and sometimes better to be decentralized. Both bits of software are made for people trying to solve similar problems, but with different nuances.
"Convictions are more dangerous enemies of truth than lies."
...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 would never use something like GIT for enterprise development.
Jesus was a compassionate social conservative who called individuals to sin no more.
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.
But you can use a git repo as a central authority just as easily as SVN. In fact that's how most projects are managed. In the case of git however you are not restricted specifically to this. So honestly I can't really think of a situation where the centralized-only architecture of SVN is actually superior.
As someone who kept SVN repos until git came to town I can tell you I've had the centralized SVN repos implode on me before. After the central repos turned into garbage the only real solution was to try and figure out who had the latest code and create new repos from that. That risk alone makes the centralized architecture completely inferior and intolerable to me.
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"
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"
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.
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.
when one member of your team decides to not play nice with the rest of the team.
If this is the case, you have bigger problems than a possibly poor choice of an SCCS.
With git, it's actually much harder for an asshole to wreak havoc, as the entire project history is cloned between all developers' machines and is cryptographically protected from being altered in ways that are hard to notice.
My exception safety is -fno-exceptions.
I thought he was making a joke on the name of the product: subversion (the act of subverting something, versus the prefix "sub" like a subordinate version). Anyway, I read the comment again and I'm wondering what he meant as well.
I have one major problem with SVN but it is a big one.
When creating branches and particularly branches of subprojects, you have to create directories with branch names.
That means that you can only compile the main branch of subprojects unless you modify your build system to take branches into account.
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)
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 one major problem with SVN but it is a big one.
When creating branches and particularly branches of subprojects, you have to create directories with branch names.
That means that you can only compile the main branch of subprojects unless you modify your build system to take branches into account.
Or, you know, you could check out from deeper within the tree. That's something that svn allows that git does not.
So, you setup your svn repo with /trunk/, /branches/, and /tags/, and then your local working copy is just, say, a checkout "svn checkout svn://your.server/svn/yourRepo/branches/foo/ localDevWorkingCopy" which is now rooted in /foo/.
A simple "svn switch" allows you to change over to /trunk/ or /tags/bar2.0 ...
This is similar to the concept of chroot in Linux (et al), but the ability to checkout part of the repo is the reason this can work in svn.
If this doesn't address your issue, then perhaps I misunderstood what you were describing.
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."
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.
Why keep that in version control though?
The tried-and-true method of just keeping around stuff like zip/tar.gz/exe files in a directory of every binary released should be fine... never delete the old releases.
>> 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.
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
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.