Slashdot Mirror
The Future of Subversion
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.
Errr. I don't see how without jumping through a lot of hoops.
;-)
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
--- Nick, hard at work
IDE integration:
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.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
- 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.Dog is my co-pilot.
Most CVCS users do work on development or experimental branches for exactly that reason. That way you can follow the 'commit often' rule. You really should only be doing merges to release branches or the trunk.
> 1. timestamps.
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.
(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. This is what object-oriented programming looks like in C, when there's no C++ to make it pretty. You have function pointers and their associated "closure' context objects being passed around everywhere as pairs. And lots of tables of function pointers (vtables). So in this example, we have a local closure object (dir_baton) referencing a vtable within a parent closure object, and calling a function from that vtable.
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.