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.
My project team has been using subversion for over a year and has nothing but good to say about it. I am really surprised so few people have heard of the project.
My group uses CVS every day. It does a great job for us.
However, some other groups in my organization like alternatives like PVCS. Now I have little against PVCS (price tag being one thing, and some crappy network functionality that likely has been resolved by now).
These people mostly like PVCS because it can do stuff like renames.
And I like renames too. And therefore, Subversion is pretty compelling. Yay! Congrats to the team, this is pretty exciting, I've been watching subversion for a couple years now. Yay!
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.
How are multiple repositories (even in CVS for that matter) handled? Anyone have any experience with either Subversion or CVS?
is anyone using this in a large professional setting? I've been tasked with rebuilding the CVS server at my gig, and I'm almost done, but how hard would it be to convert and existing CVS repository over? I will be testing the setup for a few weeks after install, so this may be a good time to try out Subversion. anyone with exp please share your thoughts. tia
CB
free ipod and free gmail!
Subversion (well mod_dav_svn) is built on a filesystem-over-http protocol, of course you can use it like a filesystem, on just about every platform, or from many applications, or through your web browser (to read it, anyway).
More secure to have a patchwork of internal user tracking built into the app instead of using the OS's user tracking?!?!?
Yes it is. It's also easier to set up and administer. Why the heck is needing root access to add users a requirement of a revision control system? It's nuts.
Stop thinking like a UNIX programmer and start thinking like a non-technical person.
I agree with you, but I think that some people can get angry when code under the bsd licence is used in a closed source project (case in point: OpenBSD in Windows Server 2003). If you are interested in the multitude of "officially" open-source licences, look at opensource.org/licences
MOUNT TAPE U1439 ON B3, NO RING
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.
Looks neat. Just checking:
Has anyone used this on Mac OS X / with xcode? I'm interested in doing so; if I want to, do I just sit down and follow the instructions or are there any gotchas or OS X-specific quirks I may run into that I might need to be aware of?
Thanks.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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?
No, junctions are for directories only. It's one of those clever hidden features of NTFS that Microsoft never bothered creating a front-end for. Hence, no way to create one in Explorer, and you must use the sysinternals tool.
And "shortcuts", as compelling as they sound to command-line hackers and programmers, are really just GUI aids. They are implemented as LNK files, which contain nothing more than info about icons, etc.
...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
Yes, and they are a PITA to use. Can't execute a link over the network, for example.
To add to confusion,
Windows only supports softlinks -- not hardlinks -- yet refers to the junctions as hardlinks in many documents.
Windows does not support softlinks off of the current partition.
Definitions...
Softlink: A pointer to a file resource that acts like the target except when deleted. If deleted, the target is not also deleted.
Hardlink: A pointer to a file resource on the local partition. If removed, the target is also removed.
Windows has pseudo links, and even attempts to fake the .lnk files for some -- but not all -- utilities. This limited support is only available on NTFS since Windows doesn't by default support anything except NTFS for this type of work.
Gripe: KDE and Gnome do not allow creation of soft/hard links and use the dummy file method (like Windows) when setting up a 'link'. I've put in a request that this be changed in KDE, though what is needed for complete consistancy is OS-level support for various device types so it is transparent to the GUI.
Bottom line: I don't know if Windows 2000 and Windows XP can support what the original person commented on...so that's the reason why SourceSafe does the goofy work arounds not needed elsewhere.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Is this likely to get Linus to switch from Bitkeeper? If not, what needs to be done to make it a suitable replacement?
As much as I'd love to see a Subversion filesystem driver in Linux, I am not sure if that would be possible. Would such a thing be legal under BitKeeper NDA to implement by Linux kernel developers?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
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.
What I'm going to do when I finally get things set up so that I'm not the only one using scm is set up staging areas as a virtual hosts on the same server as subversion. Every time there's a commit to a developer's branch, it's automatically exported to his staging area so he can test it. If everything works nicely, he can then merge into the global developer branch. Finally, when we're ready to do a full release, we merge the developer branch into the release branch, and it's automatically exported to the production server.
It's a little extra administrative overhead, but worth it for me to do the extra work, since I'm the only one on the team who's ever used scm, so I've got to make at easy for them as I can. Fortunately, for now, it's a small team, so I don't have _too_ much work to do to get it set up... and once I've got everything figured out completely, I can script adds, moves, and changes.
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."
So supposing I'm currently stuck having something like 50Mb of source code in CVS. Is there a migration tool to move it into SVN with all the versions maintained?
Karma: It's all a bunch of tree-huggin' hippy crap!
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.
Except SVN doesn't version symlinks. Or even really handle them at all, so this won't help. Of course...
Arch Does (tm).
First, it tracks changes made to files in your source tree [...]
Actually, the parent poster made *two* errors: one is the per-file behaviour, which you corrected, but the second mistake is that svn tracks *changes* .. it doesn't. It tracks *source tree snapshots* which is a subtle but important difference.
And which makes it less useful, and makes the code more complex.
Arch, as an example, literally tracks the differences between revisions, rather than the revisions themselves. From both an abstract point of view, and in the implementation.
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
The question is, what kind of developer that would need version control relies on binaries, hmm?
Windows one.
(On the other hand, most of the problems involved with setting up CVS involves pserver -- most of the people somehow decided that pserver is simpler than ssh, even if they already have ssh set up on the respository box. Go figure.)
Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
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.
You'll find a lot of corporate developers out there who reject the very idea of concurrent version control; they want a system where you have to lock a file to be able to edit it (like RCS). They want to be able to see, easily, who's working on what at any given time. They don't want to resolve conflicts -- they want to avoid them in the first place. Concurrent version control is a "bad idea" to them, and the idea of distributed repositories makes them shudder.
Now, I disagree with the lock-to-use philosophy; I know, from experience, that it causes more problems and frustration than it solves. However, the central repository architecture does have a number of benefits, not least of which is cheap copies, which leads to intuitive and elegant tags and branches.
I use darcs for my open source projects, but Subversion at work. They both have strengths arising from their unique architectures that are conducive to different development models.
I know this is slightly off-topic, but I wonder if anyone is aware of an open-source Electronic Document Management System (EDMS). The specification for CVS/Source Control and a EDMS are very similar:
- Document profiles
- Full text indexing of all documents regardless of file type
- Combined searching of both profile and full-text index
- Integration with major software applications
- Individual document security and the ability to secure whole categories (e.g. financial information)
- Version control
- Audit trail to see who has (accessed / changed / checked-out / printed) documents
- Reporting on documents (all documents used by Joe Bloggs, all documents used within last 3 months)
- Check-in/Check-out of documents
- Local copies (Mirroring) so that you do not need a network connection (allowing laptop use)
- Web-access to all documents
I wonder if anyone knows of such a system?
Sorry, that should be "ACLS still are not standard in the UNIX world".
Fedora Core 1 still, I think, does not use ACLs (by default). Most software doesn't understand ACLs. I've heard a lot of disparaging comments made on LKML about POSIX ACL design -- not sure how accurate it is, but it's there.
If I'm writing something, I can't just use ACLs and assume that they'll be there for the BSD, the Linux, the Solaris, the OS X users of my software.
May we never see th
You don't really know what you're talking about. Macintosh Aliases are not at the kernel/filesysten level (which implies that all the linkiness is taken care of for you by the library functions you call). Aliases were just data files (with file type 'alis') that the Finder (and most other applications) knew how to handle. Each program had to manually resolve aliases in the code (using one of the ResolveAlias functions). You could even open an alias file, read in the file data, and resolve the alias in memory. This allowed you to use aliases that are stored in a different manner to alias files (e.g. Mac OS shlb's allowed you to store an alias as a resource to a directory containing other dependent shlbs). Under Mac OS X aliases are still present and still (rightfully so) are not handled in the File System layer. You have to use Carbon API calls to access/resolve the alias and _more_ Cocoa/BSD code should be doing that.
I have trouble with passwords among other things.
Just as I care that my car gets me where I want to go, not how the engine works. (Yes, I know some people care how the engine works, and I'm not trying to be critical of that.)
Apple got it right with System 7 Aliases, which were symlinks at the kernel level.
Unfortunately they weren't quite that integrated - everybody had to add code to deal with aliases.
But the nicest thing about aliases is that they were really both hard links _and_ symbolic links. Both the file reference number and the file path were stored, so if you renamed a file, the hard link part still found it by file number, but if you copied your data to another harddrive, with all new file reference numbers, the symbolic part found it by file path. I think the Alias manager did the necessary repairs in both cases too.
Good stuff. 20 years ahead of its time.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)