The Future of Subversion 173
sciurus0 writes "As the open source version control system Subversion nears its 1.5 release, one of its developers asks, what is the project's future? On the one hand, the number of public Subversion DAV servers is still growing quadratically. On the other hand, open source developers are increasingly switching to distributed version control systems like Git and Mercurial. Is there still a need for centralized version control in some environments, or is Linus Torvalds right that all who use it are 'ugly and stupid'?" The comments on the blog post have high S/N.
Re:Well *I'm* ugly and stupid... (Score:3, Interesting)
If I have n users in my software team and they each have a local repository copy and "commits" that they make are made to that local repository then it basically requires me to backup everyone's PC in order to ensure that work is not lost. I don't back up PCs, we have a clear rule that if you want something to be safe it goes on the server.
Now, sure, I can see that with some effort and mucking about you can ensure that everyone's local repository copies are backed up. But this is a whole lot of hassle and I fail to see why you would bother - other than if you have a particular religious requirement to use a DVCS
Re:Well *I'm* ugly and stupid... (Score:2, Interesting)
In any event, anyone advocates distributed version control has never been responsible for protecting the work of hundreds of developers working in multiple timezones/continents. Enterprises cannot afford the cost in time and money to back up every single workstation; developers have to be given a way to sync their work, at least once a day, with a central repository that can protected against data loss.
Re:Well *I'm* ugly and stupid... (Score:3, Interesting)
Most CVCS users don't realize how incredibly useful taking branches and merging them at the drop of a hat is because they have studiously avoided it except where absolutely necessary.
we use SVN (Score:5, Interesting)
SVN is currently integrated with our IDEs (all 3), one of the main selling points in choosing a VCS.
Ease of backups:
We archive our repositories every day, IT loves being able to simply tgz the SVN directory and not have to worry about anything else, regardless of the state of any current projects (all groups use SVN).
Simplicity:
SVN/Trac training (client use, management, backend workings) takes less than 10 minutes. In another 15 minutes I can have someone setting up their own SVN repositories+Trac, without needing to pull up a single reference document, primarily because the an SVN setup methodology is trivial to memorize.
SVN's weaknesses (Score:4, Interesting)
- Merges in a typical environment become effectively anonymous. Let's say you have a build manager and individual developers working on different changes in parallel. The build manager can't merge the changes without those changes taking on his identity, that is, all identifying information about the originator of the changes is lost.
- So-called "best practice" for SVN branching means building new branches with every new release. That is, it's not recommended to build one branch and merge changes from the trunk into it as you're incrementally changing things on that branch, noooo. You have to keep polluting the repository with needless hair by making new branches every week, and sometimes, multiple ones per day.
These are just two I'm aware of that bite us in the ass on a regular basis. The first issue is supposed to be fixed in one of the near-term mods to SVN, but the fact that the second even exists tells me that the guys developing SVN don't really work in the same world as a lot of the bigger commercial development environments do.Re:Well *I'm* ugly and stupid... (Score:2, Interesting)
In my environment servers are backed up and PCs are not, which is why local repository copies I think are risky.
I appreciate that you could add this sort of feature to a centralized repository but I see that as one of the key differentiators between DVCS and CVCS. If it was a feature in a CVCS I'd be pretty negative about people making use of it without particularly good reasons...
Re:Well *I'm* ugly and stupid... (Score:2, Interesting)
Re:Well *I'm* ugly and stupid... (Score:4, Interesting)
Re:Git vs Subversion (Score:4, Interesting)
I don't see what you are talking about. git timestamps every commit too.
> 2. move tracking: trying to move a directory branch from one dir to another means you lose history.
No you don't. If you use "git mv", like you're supposed to, history moves with you.
> 3. large files. Take a 100MB binary file into SVN, change one byte, commit.
> Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
No it won't. In fact, it will use less space than SVN for that commit. Yes, git supports diffs on any kind of file, and stores them that way. It didn't always, but the current version certainly does.
> 4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir.
That's what git submodules are for. Furthermore, git repositories are smaller than Subversion repositories by a large factor. At least twice, and I've seen as much as a tenfold reduction. Linux 2.6 repository is only 255M in size, and that's a huge project. Anything you do will likely be much smaller.
> 5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily;
Bullshit. The commands are almost exactly the same. I don't know what people are complaining about.
Re:Git vs Subversion (Score:3, Interesting)
(NULL, NULL, path,
textbase,
empty_file,
base_mimetype,
NULL,
baseprops,
dir_baton->edit_baton->callback_baton));
Four level of indirection to call a method with 9 parameters... really? Come on.
Go look at GTK/GNOME: they have the same sorts of problems, though they tend to do things with a huge series of object-type macros to simulate inheritance.
The 9 parameters are there because it's a complicated routine used in different contexts. There are no 'optional' parameters like in python.