Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Subversion 1.0 Released

Posted by timothy on Sun Feb 22, 2004 10:36 PM
from the milestone dept.
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.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward on Sunday February 22 2004, @10:37PM (#8359439)
    According to the download page, binaries may take a few days to appear.

    What's so good about a version control system that takes days for binaries to appear? That's a pretty big bug to work out. (fp)
    • by Dog and Pony (521538) on Sunday February 22 2004, @11:14PM (#8359688)
      ... try having a sysadmin that prefers debian and see how long you have to wait. Sigh. I do like subversion lots though! :)
      • by after (669640) on Sunday February 22 2004, @11:06PM (#8359644) Homepage Journal
        A "binary" does not ultimately mean an executable. A binary, as you probobly know, can be any binary file sutch as a PNG image or compressed text file. The defenition is monolithic, so I can already see a mod disagreeing with me.
        • by mithras the prophet (579978) on Sunday February 22 2004, @11:20PM (#8359714) Homepage Journal
          I think he meant: if you're a programmer that plans on using Subversion, surely you can compile the damn thing yourself, rather than waiting for somebody else to do it for you.
          • Will I need MSVC? (Score:5, Interesting)

            by tepples (727027) <<moc.thgienip> <ta> <6002hsals>> on Sunday February 22 2004, @11:47PM (#8359827) Homepage Journal

            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.

            • Re:Will I need MSVC? (Score:5, Informative)

              by aardvarkjoe (156801) on Monday February 23 2004, @12:07AM (#8359914)
              Although I can't speak for the current version, I can say that it was either impossible or very difficult to compile using mingw32/msys several months back. Unless you're up for some pain, you probably ought to just wait for the binaries.
          • by tepples (727027) <<moc.thgienip> <ta> <6002hsals>> on Sunday February 22 2004, @11:52PM (#8359850) Homepage Journal

            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).

      • Re:CVS and others (Score:5, Informative)

        by Dragonmaster Lou (34532) on Sunday February 22 2004, @11:25PM (#8359736) Homepage
        CVS has nothing to with sharing code (although it can be used for that, but that's not its primary purpose). CVS is a version control system, more akin to something like Visual Source Safe.

        Basically, it serves two functions. First, it tracks changes made to files in your source tree, so that if the latest tracked version of a particular piece of code is broken, you can compare it to or even roll back to an older version of the code to either work around or diagnose what broke. Second, it allows multiple users to work on the same file at the same time without stepping on each others toes too much. This works by having each user check out a copy of the code from the main repository which contains the "master" copies of the code. When they're done working on the code they can check it back in to the repository where (often with a little human intervention) the changes are merged with the most recent copy stashed in the repository.

        Part of that does involve a central server to store repository in -- on a local network this is could often be a commonly accessable directory or mounted drive off of a WinServer/SMB or NFS server. CVS also allows for internet checkouts and checkins, which is how a lot of open source stuff is handled.

        CVS and other version control programs have lots of other features I haven't mentioned here, such as branches, labels, etc., but I figured this gives you a good idea of what's going on.

        Hope this helps.
        • Re:CVS and others (Score:5, Informative)

          by cduffy (652) <charles+slashdot@dyfis.net> on Monday February 23 2004, @12:32AM (#8359998)
          [Yes, you hit the basics -- but the implicit per-file assumption a la CVS just hit my "rant" button... hopefully some of what I'm throwing out here is actually useful].


          First, it tracks changes made to files in your source tree [...]

          While CVS tracks changes made to individual _files_ in the source tree, some other revision control systems (ie. Arch, BitKeeper, etc) store changes to the tree state atomically. That is to say, if you have file1.c and file1.h and you make a change that touches both of them, you can bundle both those changes together into one atomic operation, so that they show up as just one changelog entry and that every developer who applies one of these changes always gets both of them.

          In CVS, to know that file1.c version 1.13 and file1.h version 1.2 both belong in the same tree, you need to "tag" each file in the tree -- adding notation to the backend store for each individual file indicating that they both are tied to THIS_TAG_VERSION. In the case of a changeset-oriented system, on the other hand, the appropriate version of both files is just another element of the repository state -- so instead of a set of individual file states, you just have one big repository state that holds everything together.

          This also makes updates very fast, since instead of checking for each file "is there an updated version of this file?" for each and every file in the repository, you can just check "are there new patches for this repository?" and download that.

          There are other things one can reasonably expect of a modern revision control system, as well. For instance, a site using tla-pqm to manage their Arch repository can be set up such that only code which compiles and passes the unit tests can be merged into the primary repository; this is exceedingly good practice, especially on big teams.

          Another nifty thing good revision control systems can do (well, some of them -- Subversion, for instance, lacks this) is distributed operation. For instance, this means you can make a branch of someone else's code stored on your own server, make revision-controlled changes on that server, and then ask them to merge your changes back into their branch -- without yourself having any access to their server at all! Distributed branching, in combination with good branch and merge operators, enable quite a lot of workflows that would otherwise be quite impractical. In terms of release-quality revision control systems, the only two that really have this support are Arch and BitKeeper (svk and darcs do something similar, but neither is exactly mature or in posession of a substantial userbase; that said, I think darcs is quite interesting from a research-project point of view).


          By the way, I'm currently the maintainer of cscvs (a tool for building a SQLite database with inferred changeset information from analyzing a CVS repository's history, and then doing interesting things in it -- ranging from reporting to importing the archive into Arch), making me an interesting combination of "informed" and "biased" in this discussion. If you're interested in revision control and possibly interested in a continuation of this rant (or disagree with some part of it), please drop me an email.

  • sf.net (Score:5, Interesting)

    by RoadkillBunny (662203) <roadkillbunny@msn.com> on Sunday February 22 2004, @10:44PM (#8359492)
    Is sourceforge gonna offer this service in their project hosting instead of CVS now? Or will they allow both?
  • Works well (Score:5, Informative)

    by Anonymous Coward on Sunday February 22 2004, @10:46PM (#8359505)
    I've been using earlier builds for my own codebase stuff, and while there are a few new concepts to get your head around, overall the system works very well. I haven't had any problems with corruption or loss, and everything I've needed to do has worked perfectly.

    My congrats to the dev team for a good solid product.

    For those looking to use it, befor eyou do, work out your versioned directory structure, it *is* kinda important (although not critical, you can move things around afterwards). For example, I have:

    trunk/(project name)
    tag/(project name)/(tag)
    branch/(project name)/(branch name)

    as my general layout. Other people may have other recommendations, but tags and branches etc are no longer this explicit thing, its just about where you put them in the "filesystem".
  • Filesystem driver? (Score:5, Interesting)

    by sploxx (622853) on Sunday February 22 2004, @10:48PM (#8359522)
    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.
  • by Anonymous Coward on Sunday February 22 2004, @10:48PM (#8359528)
    Here's a comparison with 10 popular replacements

    http://better-scm.berlios.de/comparison/comparison .html [berlios.de]
  • FreeBSD (Score:5, Interesting)

    by Anonymovs Coward (724746) on Sunday February 22 2004, @10:49PM (#8359533)
    Some time ago Doug Rabson posted a wishlist [freebsd.org] 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.
    • Re:FreeBSD (Score:5, Informative)

      by cduffy (652) <charles+slashdot@dyfis.net> on Monday February 23 2004, @12:43AM (#8360036)
      Heh -- having been on the Arch list for a while, I distinctly recall watching the feature requests from Linux kernel developers ("we need $THIS before we can migrate away from BitKeeper" sort of thing).

      Their objections (other than performance, which has been dramatically improved lately) have been largely silly things, not related to the Arch core itself (which is most excellently designed; thanks Tom!), but rather mostly UI-type issues ("we want built-in a graphical 3-way merge tool!" type items).

      That's the case for Arch, anyhow. As for the post you just mentioned, its objections to SVN happen to be things that either don't hinder Arch at all or should be non-issues altogether (ie. better solution available):

      1. Equivalent to cvsup. Arch has this functionality built in, implicit in its mirroring and distributed support features.

      2. Support for (user-supplied) keywords. The general consensus on the Arch list is that it's a bad idea for any revision control system to support this "feature" at all, and that there are better ways to do anything one could want them for.

      3. Converting the repository -- cscvs, a tool I help to maintain, does just that.
  • by Catharsis (246331) on Sunday February 22 2004, @10:51PM (#8359552) Homepage
    This news post really does nothing to explain why Subversion is so much better than CVS.

    Subversion is, in essence, a reimplementation of CVS without the limitations of CVS.

    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.

    This is, IMHO, reason enough to switch. (And was reason enough to switch for me a while ago.)

    SVN can do binary-file diffs, tracks submissions of multiple files as part of the same revision, and if memory serves me correctly, does O(1) branching and tagging.

    For those of you who, like me, use TortoiseCVS to do version control in windows, there is TortoiseSVN which works like a charm and provides all the functionality you're using in TortoiseCVS with some nice extras.

    I could go on at great length, but the Subversion team can probably do a much better job explaining this than I can, so go to their web site instead.

    Quite honestly, I think that Subversion is so much superior to CVS that it will completely replace it, and I haven't got anything to do with the project. Once I switched over, I never looked back.

    1.0 release means that SVN now supports everything that CVS does, with a few extras. From here, they are planning to work on new features.

    I've heard some bellyaching over the license already (boo hoo). BSD code is Gratis and Libre, and if the Subversion team isn't losing sleep over MicroSomeone ha>oring their project into one of their own, I won't either.

    Please don't turn this discussion into another license vs. license argument, and have a look at the project for its real merit.

  • more information (Score:5, Informative)

    by j1m+5n0w (749199) on Sunday February 22 2004, @10:51PM (#8359553) Homepage Journal
    The main site seems to be slashdotted. There appears to be an online book on the subject here [red-bean.com]

    Version Control with Subversion
    Draft Revision 8770
    Ben Collins-Sussman
    Brian W. Fitzpatrick
    C. Michael Pilato

    -jim
  • by mattgreen (701203) on Sunday February 22 2004, @11:12PM (#8359675)
    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.
  • ...you could do a lot worse than TortoiseSVN (also on tigris.org). It's an explorer shell plugin with icon overlays. Open up windows explorer, right click files to comit and whoosh...it's done.

    Also has a visual diff and all sorts of other goodies in it too. There's also a (somewhat unrelated) project of the same ilk for CVS called, unsurprisingly, TortoiseCVS (different developers IIRC, same idea though, hence the similar name).

    I've been using Subversion for the last 6 months and TortoiseSVN for the last 5, never had any data corruption or borked repositories, it Just Works(tm).

    What I like is that the developers started eating their own dogfood fairly early on and have been self hosting for a fair while now, so that shows you how much faith they have in the system.
  • by joey (315) <joey@kitenet.net> on Sunday February 22 2004, @11:28PM (#8359753) Homepage
    As I type this, version 1.0 of subversion has not been tagged [collab.net] yet. I have not seen an announcement about 1.0 today, and the announcements page lists 0.37.0 as the last release.

    I think slashdot may have jumped the gun here, and I hope that the slashdotting of their web server is not going to cause them problems with actually getting 1.0 out the door, which is supposed to happen sometime Monday (timezone unknown).

  • FAQ (Score:5, Informative)

    by Anonymous Coward on Sunday February 22 2004, @11:33PM (#8359777)
    1. Subversion does NOT require Apache. It can use either Apache OR svnserve as its network server.

    2. Want decentralized subversion? Check out the svk project at http://svk.elixus.org/

    3. Best benefits over CVS? Well, its basically a 4-year redesign/rewrite/replacement of cvs by people very familiar with cvs (ie wrote the book on cvs and runs a company specializing in cvs services).

    a. Cheap copies (constant time, store diffs only so branch often if you want even on very large projects).

    b. Directories and metadata are versioned too.

    c. You can move files and directories without losing history.

    d. Atomic commits! Issue a bunch of "add" commands, then a "commit". The whole thing rolls back if any of it fails and the revision is per commit (not file).

    e. Other benefits may be more important to you than these (but these were enough for me to switch from cvs to svn).

    4. Is svn 1.0 ready for prime-time? Subversion project has been hosting itself for almost 2 years now and they never lost any code. For the ultra-paranoid, you can configure it to keep all bsdb logs so you can roll back every transaction since the beginning of your repository creation (but that would be silly).

    Don't forget to see:
    http://www.red-bean.com/sussman/svn-anti-fud .html

    And irc: #svn on freenode

  • by cheesedog (603990) on Monday February 23 2004, @12:07AM (#8359915)
    Anyone know if there is a way to use subversion for automatic canonization of code style? For example, is there a way to force the server to apply some astyle invocation via subversions hooks on any commit, and for the subversion client to apply some symmetric astyle invocation (to get the code back to the user's preferred format) upon update/checkout? Of course, code would also have to pass through the filter to check for modification, etc....

    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!

    • by feronti (413011) <gsymons@ g s c o n s u l t ing.biz> on Monday February 23 2004, @12:43AM (#8360035)

      You have 3 different places to hook into the commit cycle in version 1.0:

      • startcommit
        Before the transaction begins, you can prequalify the user for commit privs
      • pre-commit
        After the transaction tree has been completely built, but before it's actually committed to the repository
      • post-commit
        After the entire commit cycle is completed
      start-commit is passed the repository and the user, pre-commit is passed the repository and the name of the transaction (which can be examined with svnlook), and post-commit is passed the repository and the revision number. If either start-commit or pre-commit fail, the commit is rolled back; post-commit exit status is ignored.

      This could be used to canonize it coming in... it would be up to the user to reformat it coming out if desired... but everything would then get flagged as locally modified... though the user could always recanonize the code before committing... which defeats your goal of automating it all:)

      So, the grail is closer, but as always, just out of reach.

    • by fucksl4shd0t (630000) on Monday February 23 2004, @01:05AM (#8360118) Homepage Journal

      Anyone know if there is a way to use subversion for automatic canonization of code style?

      Yeah, host a python [python.org] repository with it.

  • by brettw (27391) on Monday February 23 2004, @12:48AM (#8360057)
    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.
  • by slipsuss (36760) <sussman@ r e d -bean.com> on Monday February 23 2004, @12:55AM (#8360081) Homepage
    We haven't announced 1.0 just yet; we're going to do it sometime on Monday the 23rd. The Subversion team prepped the website and rolled a 'beta' 1.0 tarball over the weekend in preparation for Monday. We wanted to make sure there were no embarrassing bugs in the tarball itself (i.e. no "brown bag" releases due to a bad libtool or something!)

    Thanks for all the nice comments. Stay tuned for the official announcement.
    • Re:Not bad, but... (Score:5, Informative)

      by OverlordQ (264228) on Sunday February 22 2004, @10:42PM (#8359475) Journal
      It's not released under the Apache/BSD License . . .

      It's released under an Apache Style [tigris.org] license.

      Google Cache [216.239.39.104] since the site seems to be dying as we speak.
    • Re:Not bad, but... (Score:5, Interesting)

      by MillionthMonkey (240664) on Sunday February 22 2004, @10:42PM (#8359477)
      What is the matter with an Apache/BSD license? Why must it be GPL?

    • Re:Not bad, but... (Score:5, Informative)

      by Anonymous Coward on Sunday February 22 2004, @10:44PM (#8359491)
      There is always GNU arch. [gnu.org] It's got some nice features that subversion does not have to boot! Such as distributed repositories, advanced merging, and GPG signed patches.
    • Re:Not bad, but... (Score:5, Insightful)

      by Anonymovs Coward (724746) on Sunday February 22 2004, @10:47PM (#8359509)
      Subversion overall looks very nice. However, I do have some issues with it. Namely, it's released under the Apache/BSD license, which I'm not completely comfortable with.

      What a strange statement. Do you use XFree86? OpenSSH? There's any amount of such software out there under similar licences, and if the original BSD TCP/IP stack hadn't been under such a licence, it's doubtful the internet would be as interoperable as it is today, and if X hadn't been under the MIT licence, we'd be stuck with a bunch of incompatible proprietary windowing systems.

          • Re:Not bad, but... (Score:5, Informative)

            by Anonymovs Coward (724746) on Sunday February 22 2004, @11:28PM (#8359757)
            Replying to myself:

            Name a single counterexample of a GPL'd library shipped as part of a commercial OS.

            Let's take two examples here: first, zlib. It was released under the BSD licence, not GPL, because it was important to wean people off the LZW-patent-encumbred compress. And it made it to commercial systems. But take, on the other hand, the readline library. This could have been immensely useful to a lot of commercial vendors, and Stallman knew it, so he used the GPL (not even LGPL) to try and "force" third party code to be GPL'd. As a result, nobody outside the free software world uses it.

    • by John Hurliman (152784) on Sunday February 22 2004, @11:05PM (#8359634) Homepage
      Just like WebDAV is an extension of HTTP 1.1, Subversion is an extension of the WebDAV protocol. This means that:

      * It can run as an Apache module or a standalone server
      * It can go anywhere HTTP goes (including caching proxies) as it runs entirely over port 80 with WebDAVish calls.
      * It implements part of the WebDAV protocol, and in the future might fully implement it meaning seamless integration in to software like Macromedia Dreamweaver.
      * Uses Apache for the authentication, so you can authenticate with any module you find/write.

      Right now our WSU Linux User Group is using Subversion for development. Authentication is tied to a PostgreSQL backend that is shared with the Zope/Plone server, so an admin can login to the Member panel and add/remove people from the developer group to give or take Subversion access. A real WebDAV folder is also setup that shares the same authentication method. Now we just have to tie in mail server and ssh authing...
      • by SewersOfRivendell (646620) on Sunday February 22 2004, @11:36PM (#8359789)
        All of the above is true, but I'd like to clarify that Subversion is a set of version control libraries, on top of which are built the clients and servers, it's not just an implementation of the WebDAV DeltaV protocol for Apache.

        For example, there's also a supported custom network protocol server (svnserve, uses "svn://" URIs) for those that don't/can't maintain Apache w/mod_dav.

        (And everything else people say about how cool Subversion is -- is true! Really, check it out. Sourceforge should switch over ASAP.)

    • by ewhac (5844) on Sunday February 22 2004, @11:17PM (#8359703) Homepage Journal

      It's possible, through a variety of easily-made missteps, for a file to lose the tag that marks it as binary. Suddenly, fresh checkouts of the file have newline translations done on them, and all hell breaks loose. And, if you edit the ,v file that stores the revision history, you'll discover that the binary file is actually stored as a raw byte range within a text file.

      So, yeah, RCS supports binary files. It just doesn't do it very well.

      Schwab

        • by orthogonal (588627) on Sunday February 22 2004, @11:32PM (#8359774) Journal
          Do not mod up people who point out cut-and-paste trolls logged in.

          Many of these are folks who post plagarized articles and then point it out with another account to gain karma.


          Do not mod up ACs who point out that people who point out people who post plagiarized articles.

          Many of these are folks who are stuck in a bizarre recursive process of accusation and counter accusation against
          folks who are stuck in a bizarre recursive process of accusation and counter accusation against
          folks who are stuck in a bizarre recursive process of accusation and counter accusation against
          folks who are stuck in a bizarre recursive process of accusation and counter accusation against

          Oh, wheels-within-wheel-within -- oh just take the blue pill!
      • Re:GREAT! (Score:5, Informative)

        by Anonymous Coward on Sunday February 22 2004, @11:41PM (#8359810)
        Subversion can be centralized (used as-is) or it can be decentralized (used with svk).

        More info on svk: http://svk.elixus.org/

        The beauty of being designed from the ground up to be a set of C APIs allows it to be used in any way you want.

        For me, I like using it with ViewCVS and TortoiseSVN (similar to the awesome TortoiseCVS extention to Windows Explorer).

      • Linus wants a distributed system, which Bitkeeper is.

        Did Linus evaluate GNU Arch [gnu.org]? 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 [berlios.de], 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?