Slashdot Mirror
Subversion 1.0 Released
Phil John writes "Subversion 1.0 has finally been released. The people who maintain CVS have given us a viable replacement for our de-facto (and aged) versioning system. If you're new to Subversion its feature list looks like fixes for everything that is wrong in CVS, renaming, directory structure and metadata version tracking, file deletion, proper management of binary files and it's pretty portable to boot." According to the download page, binaries may take a few days to appear.
What is the matter with an Apache/BSD license? Why must it be GPL?
Is sourceforge gonna offer this service in their project hosting instead of CVS now? Or will they allow both?
Cheers,
RoadkillBunny
Is there a filesystem that uses subversion as it's underlying "device"? For linux?
Some time ago I worked with Rational ClearCase and the filesystem integration was really nice.
I've always hated that about CVS and Arch.
A revision control system should simply work in one UNIX account across all users - it's easier to administer and is much more secure.
Some time ago Doug Rabson posted a wishlist of features that would be needed to move FreeBSD to subversion (from CVS). Any idea on progress on these features? The site seems to be slashdotted.
It's slashdotted already but I'm pretty sure the bianries they are talking about are binaries of the server itself (so you don't have to download the source and compile it yourself to run it, rather than it not supporting binary files in the tree itself.
Normal people worry me!
SourceForge said in a FAQ (IIRC of course) that they are waiting until a production version of SVN comes out. Now, when will they implement it? I'm waiting pretty anxiously.
Problem here is that many open source projects for Microsoft Windows will compile only on Microsoft Visual Studio, which costs over 1,000 USD for one seat. Will the Windows version of Subversion compile cleanly on MinGW+MSYS? Or will I have to try to compile the UNIX version on Cygwin? I'd go look myself, but the site seems to be slashdotted, and even the Google Cache runs extremely slowly because Mozilla won't render anything until it has failed to fetch the CSS from the slashdotted site.
it always worries my when open source software relies on closed-sources or standards.
Very little demand seems to exist for completely open-source PCs. I haven't seen many computer manufacturers ship their machines with LinuxBIOS or any other Free firmware. Therefore, on most computers, LILO and GRUB (the most common Linux bootloaders) rely on a proprietary BIOS. Even if you exclude BIOS from consideration, most Free programs running on a proprietary operating system rely on the proprietary system's runtime library (e.g. msvcrt.dll, Sun libc, etc).
Yes, my team does this. We have a web and java based scheduler application.
Our source is maintained with subversion and we have teams that concurrently work on different layers (data provider, ui, business logic). We run the project on jetty currently, even with two ui frameworks (struts+velocity and tapestry).
We use maven to build the war file, and start the appserver (with a patch we wrote to support jetty). This works very well for our team of around 14 people.
And yes, I know that some of you think this is a terrible, horrible idea and that my keyboard should be confiscated for even suggesting it. But this ability is on my "holy grail" list for version control systems, and I won't rest till I find it!
Linus wants a distributed system, which Bitkeeper is.
Did Linus evaluate GNU Arch? If so, what did he find wrong with it? One of the goals of Arch is to replace Bitkeeper. Yes, there exists one known feature that Arch lacks compared to BK, namely copying files within a repository while forking its change history, but why did Linus find this a showstopper? Or has Arch progressed rapidly since the BK decision?
...it's meant as a general file versioning system. However, there are indeed various hooks so in theory you could set something like this up. Have a look at the subversion book (linked elsewhere in the comments).
I am NaN
Is this likely to get Linus to switch from Bitkeeper? If not, what needs to be done to make it a suitable replacement?
I've been following subversion for 2 years and waiting for it to be ready.
Last build we tried was a couple of months ago.
Try compiling it on different architectures (ours are i686-linux and hppa2.0-hpux11.00), mixing slight version differences, mixing which server you use (svn, http).
Then say hello to _constant_ intervention by someone who has admin privileges to recover your hosed repository.
I hate to say it, but now of course with 1.0 we'll try again. But I wouldn've thought they were a long way off based on our problems.
And this is with just 3 people using it on a test project? CVS has bugged me for years, but it can handle the basics without error.
I'm willing to admit that something we did could've caused all our problems (funny compiler flag or version, wrong switch enabled), but I can't afford the time spent trying to get a superior, but buggy, tool to just do the basics, even if the root cause is in some arcane step in the build process (which is truly hideous).
I wish them luck, but honestly I've never been able to figure out how all these happy subversion users ever got it to work.
There's still time though to pull the plug on our imminent order of Bitkeeper if by some miracle things have improved a lot very quickly.
Granted, it would be great to finally see Subversion nicely integrated with SourceForge, but CVS (the current concurrent versioning system used by SourceForge) while lacking lots of essential (at least for experienced developers) functionality, is free software nonetheless. What I am most concerned about is whether this new version of Subversion is already good enough to use with Linux, so one could contribute without the need to choose between restrictive EULA and being a second class citizen. Does anyone know what features exactly does it still lack, if any, for Linus to accept? I hope it would be legally possible to accept now, but I might be wrong.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
It has basically the same functionality as CVS, but is based on a BerkeleyDB backend instead of a simple filesystem approach like CVS. This means, among many other things, that you can move files from directory to directory and rename them without orphaning them.
,v files or Subversion's database backend).
Bogus. GNU Arch is based on a filesystem-based repository as well, but can revision file moves, permissions, symlinks, and so forth.
Further, even if the Arch tools were to disappear tomorrow, I could still retrieve the contents of my files using tar, patch and similar tools -- something I can't do with a tool that backends into BerkeleyDB. (Yes, call me paranoid -- but I don't trust my source to big binary blobs managed by the same library that's destroyed my RPM database so many times). The repository format is write-once, so the files in the repository, once created, are never overwritten or modified as new history is added (unlike CVS's
There are other reasons to prefer Arch as well, including distributed repository support, history-sensitive merge operators, and arguably superior core design.
Yes, I'm glad to look at SVN on its merits alone -- and while it's a huge improvement over CVS, I still find it lacking compared to the other modern revision control systems out there.
I can't be the only one that is unimpressed by Subversion.. and a little disappointed that this is the best the open source community can come up with.
When I first started reading about Subversion (a few YEARS ago), I was ready to be blown away. I thought it would be fast and powerful, yet light and minimal like CVS. And I expected features like distributed repositories and changeset management built in from the start.
But after using it for a while (and I have been using it for a couple major projects) and studying the design, I don't like it much.
One thing that's great: they stripped down the CVS interface, and removed all the confusing and conflicting commands and flags. svn now has a nice orthogonal command set, but still easy to use for a CVS old-timer.
But under the surface.. WOW a berkeley DB? Implementing a *versioned filesystem*? Talk about over-engineering!!
First of all, a versioned filesystem is not the right solution for version control. Version control is about *changesets*, not file snapshots. Subversion is concentrating on the nodes of the change graph, not the edges. Their solution is extremely "heavy". Changesets cannot be added to this model. It's possible to *generate* changesets from various snapshots of the tree (i.e., which sets of revision deltas make up a particular changeset), but that's also possible with CVS and a horrible hack.
A better solution would be designed around changeset management from step 1. And it wouldn't take X years to finish.
Second, the Berkeley DB is a key/value database. What the heck does that have to do with versioned trees?
Berkelely DB installations are difficult to back up, they can't be placed on network drives, they have locking issues, they create journals and logfiles and all kinds of junk. To back up our svn repositories, I'm just dumping the whole damn thing every night into a massive text file. Yeesh. (Actually it's not a text file, the binary files are dumped right along with the text, so it's actually a binary format).
Want another example of using berk DB where it shouldn't be used? The RPM package manager. A huge pain in the ass, but that's a rant for another day.
And yeah the WebDAV thing (which was installed by default when I installed svn from FreeBSD ports) sucks too. Maybe when I have some time I'll figure out the non-Apache dedicated server. But the WebDAV server should just be dropped completely, imo, it seems to just piss people off.
The Subversion folks should've been much more minimalist in their design. They should've aimed for the *simplest* design that could meet the requirements.
I've taken a look at Arch, and it has the opposite problem of subversion: damn nice internal design, but crappy interface (I recall the help text that listed commands was almost 200 lines long)!
Internally arch is great. It doesn't need any fancy database, all you need is a filesystem with atomic renames and other Unix-y features. It handles changesets, it handles distributed repositories, it handles "checkpointing" complete copies of the source code (so you don't have to spend a lot of time applying deltas to get to a specific revision)... it does it all once you figure it out.
The subversion folks should've taken Arch, cleaned up the interface, come up with some compatibility code for non-Unix platforms, and called it a day.
Ahh, but that would've been too easy.
The BitKeeper model is so breath-takingly elegant. I used Sun's TeamWare (BitKeeper's predecessor) with great success, and am sorry to have to use Perforce in my current job.
The idea is that there are no branches. There are only repositories (each developer has one or more) and files. Each repository has full information of the version history, and there's no version control server.
Benefits of the BitKeeper model:
- Exchanging changes between developers without contaminating the common parent repository is safe and trivially easy.
- You check files in locally in your repository. So they don't even have to compile. It's often a good idea to check in files several times a day. Committing the changes to the parent repository is a separate operation.
- The repository is little more than a directory tree containing SCCS files. Should you want to liberate yourself from BitKeeper and go with a free competitor, chances are your SCCS tree can be accepted as-is by the new version control system.
- Since releases are managed as repositories (instead of branches), bug fixes can be propagated between releases as simply as within releases if there are no conflicts.
- Since there is no central server, transporting repositories, say, from hard disk to hard disk is as simple as copying the trees recursively.
We replaced 2 huge SourceSafe and 8-10 enourmous CVS repositories with Subversion.
We kept dual copies for about two weeks before feeling concident (only two projects was actully active, but with > 140 developers).
This was in the 0.27 version and haven't had a single glitch!!! And 1.0 is even better, of course.
My only complaint is not supporting locking, but this is obvisouly on the way. Nice for stuff like Word documents and UML files.
GO SUBVERSION!!! Also try TortoiseSVN... it's the best client and integerates nicely with the explorer. If you use Linux, there are lots of options too.
Your distinction between soft and hard links doesn't make much sense. I don't think there's any type of link that, when deleted, also deletes the target. The way I learned it:
Softlink (aka symlink): Has it's own file, but any access gets routed to the real file. This is what most links I deal with are. If you delete the real file, the link breaks, but stays there.
Hardlink: Doesn't have own file. Behaves exactly like the original in all ways, but has a different name. If you delete a hardlink or the original file, nothing happens until *all* instances are gone. Hardlinks must be on the same partition.
In Linux under ext2, hardlinks are files with the same inode number. I don't know exactly how softlinks work, but they have different inode numbers than the original.
Windows with NTFS supports hardlinks as mentioned in other posts, and softlinks as shortcuts.
So to sum up, the links you were referring to were hardlinks, and as such rightfully can't go across network. The pseudolinks you were talking about are simply shortcuts, and usually don't work in applications due to shoddy programming.
Karma: Contrapositive
I'm glad to know an informed statement like "Arch is crap" and limiting its user base to "3 brain dead people" can get moderated to +1 so easily at Slashdot.
First, to address your claim on GNU Arch's quality, I'd like to point out that it's not meant as a correctional to CVS like SVN is -- the best description I've heard of it is as a formalization and automation of the development process that the GNU project used before Cygnus introduced networked CVS as an easier but more limited method.
One of Subversion's most important features in my mind is that of whole source patches (I think they may call them atomic patches or something). Good job SVN team (this is in all seriousness; I'd be foolish to wish harm on any F/OSS project). However, they've fallen down in the much more critical area: providing distributed development.
If CVS and SVN are the Cathedral, Arch is the Bazaar. When SCO posted their "Reasons to use SCO UNIX" list, one of the items was (paraphrased) "A single vendor" which most people criticized as being "a single point of failure" and I fail to see the difference in using a CVS or SVN archive. Witness the damage caused by Savannah getting compromised -- what if the same had happened to Sourceforge? (Arch has added GPG signed archives to address this issue.)
The freedoms held so dearly by the GNU project and the FSF are our freedom to make changes, but with centralized development tools like CVS and SVN, third party developers are second class citizens at best forced to get permission from the maintainers to make any changes -- patches must either be submitted via email or the client must ask permission to get added to the permissions list.
I don't like that.
And I'm sure many other people don't -- how many projects in our history have been forked because people had too much difficulty getting their patches into version control? Would OpenBSD have forked if Theo de Raadt could have still submitted his patches to NetBSD? Would EGCS have forked if the GCC steering committee could have gotten their patches in? Would Keith have forked X? Would XEmacs have forked FSF Emacs? The list goes on...
People don't like being treated like shit, and if you're going to treat them that way, expect them to do the same to you. Hackers are just like any other artisan -- they're proud of their work and if you treat it poorly, they consider it an insult to them. You don't necessarily need to accept someone else's patches into your own code, but you still need to respect their right to have their patches treated just the same as yours are treated (just think Voltaire as a modern day hacker: "I may not agree with what you code, but I defend to death your right to code it.")
As for the user base, aside from being self hosting, projects that are maintained using Arch include Rhythmbox, Squid, Xouvert, Y Windows (or so I'm told), and a few others (at least some other GNOME projects IIRC). GNU Emacs has added arch-tag lines to the source code to facilitate a change in the future, and the Linux source code is mirrored under Arch (a change from Linus to arch is pending *at least* some speed increases on large source trees and probably some more support/documentation).
I'd tell you to read some background on projects before making your stupid claims, but this is Slashdot so I don't know what the point is. Readers, please mod down the parent.
-jivera
Many of the core Subversion developers are former CVS hackers. If they say the code they worked on for years is unmaintainable I believe them. CVS had fundamental (and obvious) architectural issues which you cannot solve by adding a bugfix here and a new feature there. Sure, it took a few years to make svn just do everything CVS already does, but did it harm anyone? From now on there is a much cleaner codebase which is easier to extend with new features, has less surprising corner cases for users, and makes it easier for new developers to start hacking it.
Although I am still undecided whether svn or arch will replace CVS for me (arch is nice, but its non-portability sucks, and whoever came up with the idea that using all kinds of funky hard-to-type script-unfriendly characters in filenames would make a vc system better in any way should be taken out and shot), I completely support the decision of the svn team to start from scratch.
Programming can be fun again. Film at 11.