Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Software

Subversion 1.1 Released 60

Posted by Hemos from the testing-the-difference dept.
crafterm writes "Subversion 1.1 has just been released with many new features, including performance speedups, a new file based repository format, localized messages, and more. Release notes are available http://subversion.tigris.org/svn_1.1_releasenotes. html"
This discussion has been archived. No new comments can be posted.

Subversion 1.1 Released More

Subversion 1.1 Released

Comments Filter:

  • CVS-Subversion anyone? (Score:3, Insightful)

    by Dr. Bent ( 533421 ) <`ben' `at' `int.com'> on Thursday September 30, 2004 @05:04PM (#10399408) Homepage
    Anyone out there move an existing project from CVS to subversion? Can you enlighten the group with your reasons why?

    Thanks.

    • Re:CVS-Subversion anyone? (Score:5, Informative)

      by Cecil ( 37810 ) on Thursday September 30, 2004 @05:26PM (#10399561) Homepage
      Can you enlighten the group with your reasons why?

      Hmm, let's see:

      - No more vendor branch initial import silliness
      - Even easier, faster branching
      - Can point someone directly to a specific branch via URL
      - Built-in repository browsing (via http)
      - No lockfile headaches
      - In general: faster, cleaner, more polished, slightly more streamlined workflow.

    • Re:CVS-Subversion anyone? (Score:2, Informative)

      by Anonymous Coward
      Well, I can tell you why I'm NOT:

      CVS works fine for me and works on all my machines. The only problem is the UI of the cvs command line tool which is a little crusty (how exactly do you import an existing code base into CVS again?).

      Also I DO NOT like the "do-it-yourself" branching/tagging of Subversion. I like to use lots of floating tags, before and after big changes, pre/post merge markers, etc., and doing it subversion's way is just weird. I can appreciate the thinking behind it (hey, it's just more v

      • SVK. :-) (Score:5, Interesting)

        by autrijus ( 48596 ) * on Thursday September 30, 2004 @05:54PM (#10399764) Homepage
        However I'm keeping my eye on it. When they support changesets and distributed repositories, as well as transparent CVS support for legacy clients, I'll be first in line.

        In that case, do check out the svk [elixus.org] project, which supports distributed repositories, transparent CVS mirroring, and has an almost identical command set as Subversion.

        One thing I really like about svk is that it can choose to present itself as a "single stack of revisions" monolithic system, or as a "multiple stacks, star-merged back and forth" decentralized system, or even a "shallow stack of patch chains, swapped freely" system, based on the current needs of the user.

        I am implementing a darcs-compatible command set [elixus.org] and patch tracking algorithm [elixus.org] for svk, which should be merged to the main trunk on 0.23 or 0.24,

        Also, svk interoperates [elixus.org] with existing p4, cvs, svn (and soon arch) repositories, as you don't have to convince everybody else to use the same system.

        I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.

    • Re:CVS-Subversion anyone? (Score:5, Informative)

      by lonenut ( 165873 ) on Thursday September 30, 2004 @05:58PM (#10399786)
      I have worked extensively with CVS in the past, but my current project has adopted Subversion. Subversion corrects several deficiencies in CVS while retaining a very similar command syntax.

      Improvements include:
      - Atomic commits
      - Historically trackable file/directory renames, moves, and deletes
      - Simplified branching and tagging
      - Less network traffic between client and server
      - Better binary handling

      The big missing component at this time is robust merge tracking. You have to do a little manual work during complex merges from long-lived branches, but that should be addressed in 1.2 or 1.3.

    • Re:CVS-Subversion anyone? (Score:5, Informative)

      by legLess ( 127550 ) on Thursday September 30, 2004 @06:09PM (#10399866) Journal
      My reasons:
      • Subversion keeps a local "pristine" copy of your current version. This means that many operations don't require an accessible repository.
      • Subversion actually deletes files (and moves) when you ask it to, rather than the two-step operation required with CVS.
      • Subverison makes atomic commits -- if one part fails, it all fails.
      • Subversion sends diffs to the server, not the entire bloody tree.
      • Branches and tags are very simple and constant time -- they're kept not as complete trees but as diffs of their predecessors.
      There are other reasons, to be sure, but these are what I like the most.

    • Re:CVS-Subversion anyone? (Score:5, Informative)

      by mr3038 ( 121693 ) on Thursday September 30, 2004 @06:25PM (#10399977)
      I ported our inhouse CVS repository to subversion (svn) mainly because svn supports renaming and moving of files and especially directories. Later I've found that I'd rather take system based on 'changesets', but luckily svn can emulate those suprisingly well with it's -rN:M syntax.

      For example, if I want to import changes between revisions 123 and 124 from trunk to current branch, I can just use svn merge url://path/to/repo/trunk -r123:124 and all changes in the trunk between those revisions will be merged in the current branch. Note that a revision is always the result of a commit and might include changes to a bunch of files and directories. And if something has been renamed in that commit, that change will be included too! If it later comes out (possibly after 10 more commits to the very same files) that such a merge was mistake, I can remove that merge just as easily with svn merge url://path/to/repo/trunk -r124:123. Note that I just reversed the repository numbers, so svn applies changes in reverse.

      There're some things I don't like, though:

      • CVS was faster in many simple cases like, for example, cvs commit. I've been told that SVN has much faster branching and other stuff that I never learned how to do with CVS. Branching is fast, I have to admit that.
      • svn has no tags or branches (or it has both but those are "only" full copies of the "branch source" directories). I'd also want to give revisions symbolic names (this is how I understand "tagging") so that I could refer to special revisions by name instead of some random number.
      • svn stores all data in a database. Fortunately 1.1 seems to fix this. If you have really many developers accessing the repository a database might be the best choice but for smaller projects it was a bit too complex system. Now svn can support both systems and you can start with fsfs-backend and later upgrade to real database if you really need it.
      • If I don't remember to run svn update every now and then, I end up with "mixed working copy" which isn't always a good thing because "mixed working copy" has some serious limitations in the current implentation. You might end up needing to run svn update even when you don't want to do that.

      Just give the cvs2svn a try and play with svn with some real world sources. And keep the CVS repository running until you're comfortable with svn. Then use cvs2svn to do the conversion.

      • tags and branches are just copies, and copies are very cheap space-wise in SVN. It's really quite clean. Mainline development in /trunk, branches under /branch/ and tags in /tags/...

        • tags and branches are just copies, and copies are very cheap space-wise in SVN. It's really quite clean.

          okay. But now I have numerical revision "names" and I'd want to give more meaningful names for commits/revisions, how do I do that? There's difference between knowing that difference from r123 to r124 is bug fix to bug number 42 and having r124 an alias called bug42fix. That way I could more easily merge that fix to another branch. But I guess it all comes down to svn not really supporting changesets.

          • You do:

            easy:

            svn checkout -r 124 $REPO/trunk
            svn cp trunk/ $REPO/tag/bug42fix

            So $REPO/tag/bug42fix is $REPO/trunk at revision 124 forever, until the end of time. Or until you delete it.

            If you commit to that tag, it becomes a branch.

            Also, copying is light-weight. Even if /trunk is 20MB, the copy will only use a few kilobytes of repository space.

            So, a tag is a copy you don't commit to, and a branch is a copy you commit to. Tags don't even have to be under /tags, but that's what most people do. the SVN boo
    • I run a website with a membership paradigm, where the members have access to the source code, but only select developers can commit changes. We recently switched from CVS to Subversion, and I must say that the process was rather painful. People told me that svn supported various things, and convinced me to make the upgrade; they were largely incorrect, and this "CVS replacement" doesn't really deserve to be at 1.0, let alone 1.1.

      You can download a pre-compiled binary, but it was several builds behind and
      • It seems like most of your problems stem from trying to do complex access controls without using Apache2. Run an apache2 instance on a loopback interface and forward to it with mod_proxy. Then you have all the nice, fancy ACLs and authentication of apache2 and mod_dav_svn without having to trust your entire site to Apache2. svnserve is not intended to be robust and fancy, it's best suited for when you absolutely cannot use Apache2 to provide repository access. mod_dav_svn works a lot better.

        Also, complaini

        • Re:CVS-Subversion anyone? (Score:2, Informative)

          by nuba ( 660398 )
          Lets see, the access methods are ssh, local fs, http, svnserve... all which allow per-user permissions in any recent version. Grandparent just didn't rtfm.

          • Re:CVS-Subversion anyone? (Score:2, Informative)

            by nuba ( 660398 )
            Alright that was a little harsh :P To clarify, you can do it with things like multiple instances of svnserve and group permissions. Through apache2 it is simple with the authz module.

      • Re:CVS-Subversion anyone? (Score:5, Informative)

        by nthomas ( 10354 ) on Thursday September 30, 2004 @08:03PM (#10400617)
        You can download a pre-compiled binary, but it was several builds behind and missing some vital features when we made the switch, and so we had to compile from source.

        I fail to see how this is a Subversion problem. The developers (almost none of whom get paid to work on the project) shouldn't be required to compile binaries for every operating system out there. That should be the job of your OS's package maintainer.

        There are numerous dependencies that are all in unstable status, we had to upgrade and recompile half the server platform just to get svn built.

        I think you're abusing the word "unstable" here. Subversion may use the latest and greatest versions of some libraries, but I don't think any are in alpha or beta status. (Could you point out any that are?)

        Now, if you are having problems with your dependencies not being up to date, take that up with your package maintainer, whoever that may be.

        CVS allowed per-user authentication, such that I could set up some users to be authenticated as read/write and others as read-only, for the cases when a non-committer needed an update of the code immediately without us having to go off and build a tarball and have them download it. Subversion does not support this, instead allowing "anonymous" and "authenticated" access levels - you're either logged in or not, and get read/write permission accordingly, with no ability to configure permissions on a per-user basis.

        False.

        Subversion most certainly allows you to configure permissions on a per-user basis. It even goes so far as to allow you to fine-tune those permissions on a directory level (i.e. /src/foo is read-writeable while /src/bar is only readable and /src/quux is off-limits).

        Don't place the blame for your failure to thoroughly read the documentation on Subversion.

        CVS allows you to use a standard htpasswd file for storing hashed passwords along with user names. Subversion requires the passwords to be in plain text mode, so I had to ask all my developers to generate random passwords so that I wouldn't be accidentally exposed to passwords they use for other things.

        This issue has been beaten to death several times on the mailing lists. Please read the archives.

        We can't use the web-svn server because it needs to run through Apache 2.0 and we're running 1.3 still, without the option to upgrade because of some other plugins that haven't been ported.

        And who said you have to upgrade your webserver to run Subversion? You can run Apache 1 and 2 just fine on the same machine, just use a different port for Apache 2.

        Overall, I'm not very impressed with Subversion, and will probably still keep updated my CVS repository in parallel until SVN gets its act in order. I'll take a look and see if 1.1 fixes any of my complaints.

        Overall, I'm not very impressed with your inability to read documentation before you make uneducated statements like "People told me that svn supported various things, and convinced me to make the upgrade; they were largely incorrect, and this "CVS replacement" doesn't really deserve to be at 1.0, let alone 1.1."

        Subversion, like any other tool, requires a bit of effort to switch over to. But the Subversion devs are smart people who have dealt with (and solved) all of the issues that you brought up. It is not perfect, but it is being actively developed and baseless complaining doesn't help anyone. In future, I advise you to read the docs completely, and ask the proper questions in the proper channels before you begin to criticize.

        Don't get me wrong, Subversion has its share of problems. Some of these can be fixed, others require significant design overhauls before they can be addressed. But unfounded claims such as yours shouldn't need to be addressed several times per week just because you can't be bothered to look into them properly.

        Thomas

    • If I remember well, Debian moved everything to subversion a while back. I don't think you will ever see a larger transition.
    • I think the reverse question is more relevant. Why exactly are you sticking with obsolete stuff like CVS? Maybe you have valid reasons (i.e. maybe there's something that should be implemented in subversion)?

      I use subversion on a daily basis and I find it is much less a PITA than CVS which we still use for older projects (we never did a migrate but just started using subversion for the new stuff).

      Fast & painless merges, branches & tags, transactional commits, versionmanaged file & directory nam

  • Free book online (Score:5, Informative)

    by prostoalex ( 308614 ) on Thursday September 30, 2004 @05:10PM (#10399451) Homepage Journal
    There's a free online version of O'Reilly's Version Control with SubVersion [red-bean.com]

    • Re:Free book online (Score:2, Informative)

      by nuba ( 660398 )
      PTR is working on a Subversion book in the Bruce Perens Open Source series. They've sent me a couple chapters to review and it looks like its coming along. It's still a ways off, but it should be nice once its released.

  • here is a good example (Score:5, Informative)

    by Da_Slayer ( 37022 ) on Thursday September 30, 2004 @05:25PM (#10399550)
    The apache webserver [apache.org] is switching to subversion. This was said in the mailing list post here [theaimsgroup.com] and if you follow the thread it gives some good reasons behind using subversion. Examples from the original proposal include mod_dav_svn and mod_authz_svn which are Apache modules for web interface to the source repository.

    Other examples include The Commons TLP and the SpamAssassin project which are projects of the Apache foundation are already using subversion. To see all the projects Apache foundation projects using SubVersion just go here [apache.org]

    Useful links: Subversion homepage [tigris.org]

    Version Control with Subversion Book (mirror) [rush3d.com]
  • Woo hoo. 1.1 allows us to create repositories in the flat filesystem. Sorry, I'm not a big fan of BerkeleyDB.

    But what I'd really prefer is if they moved the SQL RDBM backing feature up as a nearterm goal (roadmap say longterm). :)
    • Why is the new fsfs repository such a big deal ?(unless you do store it on network filesystems?)

      There is the little note;
      "Note that the data files created by fsfs repositories are still in a binary format, and are not human editable!"

      And can it do hot backup, with guaranteed atomicity ?

      • Re:No more BerkeleyDB! (Score:5, Informative)

        by nthomas ( 10354 ) on Thursday September 30, 2004 @07:21PM (#10400378)
        Why is the new fsfs repository such a big deal ?(unless you do store it on network filesystems?)

        It is a very big deal if you've used Subversion for any appreciable amount of time. See my other post in this thread for a more detailed overview of BDB vs. FSFS. Or just take a look at the Greg Hudson FSFS document. [mit.edu]

        There is the little note; "Note that the data files created by fsfs repositories are still in a binary format, and are not human editable!"

        Which brings up the question, why do you want your repositories to be human editable? With CVS, you needed it because CVS regularly screwed up your repository, with Subversion, that's guaranteed not to happen.

        Also, when you use apps that use Berkeley DB, PostgreSQL, MySQL, Oracle, MS SQL, Sybase, or DB2 as a backend, does it bother you that your data is not human editable? Why should you worry so much about Subversion then?

        And can it do hot backup, with guaranteed atomicity?

        Yes, "svnadmin hotcopy" works just fine.

        Thomas

        • > Which brings up the question, why do you want your repositories to be human editable? [cut] with XXX, that's guaranteed not to happen.

          Yeah, right with *any XXX* corruptions can and will happen (rarely yes, but it will) unless your SW is garanteed to be bugfree..

          Note that even with a human editable SW, the corruption can be so severe that you can't fix it (or it is time consuming).

          So backup..

        • Which brings up the question, why do you want your repositories to be human editable?

          I find "grep -ri blah /../cvsroot" rather useful. I suspect I'm not the only one.

      • BDB can have issues across different builds. You cannot just tar up a repositor, send it somewhere else, and expect them to be able to use it. Also, certain versions of BDB that distros ship have been known to cause problems. A lot of the issues on the mailing list are caused by BDB. If a BDB file is corrupted, you lose everything. FSFS keeps revisions as files I believe. This means _should_ anything go wrong (is very rare as is) the damage should be contained to the last revision.
        • If you want to send a repository, or a portion of a repository, for use elsewhere, just dump the data using the "svnadmin dump" command. The recipient can put the data into a new repository with the "svnadmin load" command.

          The existence of a repository, or a database storage component in the repository, does not relieve you of the necessity of making backups of the repository.
        • True, but it was never meant to do things like this.
          Btw, what would taring up your repos do if someone happened to
          commit at that point ?
          svn ships a tool that (atomically) dumps the db in a textual representation, to be able to load it back regardless of platfor/version trouble.

  • Other reasons... (Score:4, Informative)

    by MobyDisk ( 75490 ) on Thursday September 30, 2004 @06:16PM (#10399911) Homepage
    Transactional database format
    True client - server
    Encrypted passwords
    Built-in SSH support

  • FSFS (Score:5, Informative)

    by nthomas ( 10354 ) on Thursday September 30, 2004 @07:09PM (#10400299)

    One of the bigger changes that users of 1.0.x will see when upgrading is Greg Hudson's awesome new FSFS filesystem.

    Subversion uses a db-like transactional filesystem to store your files, up until v1.1, Subversion used Berkeley DB to implement this filesystem. But BDB was somewhat of a headache for many Subversion users. Some issues:

    • no networked filesystem - since BDB (along with many other databases) used file locking features that were not available over network shares, you couldn't host your Subversion project over NFS/AFS/CIFS(Samba).

      With FSFS this problem is gone.

    • wedged repositories - for some people their Subversion filesystem would inexplicably "lock up", requiring the sysadmin to run "sdvnadmin recover" on the repo. It was actually BDB that locked up, and sdvnadmin recover actually ran the Berkeley DB recovery procedure on a repository, but most people blamed Subversion.

      This never happens with FSFS.

    • smaller repositories - because it stores deltas, FSFS repositories are smaller than BDB ones. Greg Hudson's FSFS documents claims that "space savings are on the order of 10-20%", but that's a modest claim. I've personally seen myself (and others have mentioned) significantly smaller repos when switching over to FSFS.

    Of course there are a ton of other nice fixes and improvements to 1.1, but FSFS shines above the rest. Also, there are rumors that FSFS will soon become the default filesystem in Subversion, I for one will welcome that change.

    For more information about FSFS, Greg Hudson's original FSFS document [mit.edu] is required reading.

    I'm sorry if this post comes off as Berkeley DB bashing, I really didn't intend for it to be like that. To be fair, I think that Subversion put DB to use in ways that perhaps it was not intended to, and coupled with the fact that Berkeley DB is mostly a commercial product, I can sort of see why an opensource project like Subversion would take backseat to Sleepycat's paying customers. (I should probably mention that Sleepycat recently placed one of their employees as a "Subversion liaison" to help resolve BDB bugs/issues quicker.)

    Thomas

    • Yes, FSFS is a big deal. I'm looking forward to migrating my customers over once it gets a little more real world testing :) BDB although great overall is the source of a pretty large number of the problem emails on the mailing list.

  • distributed systems are more interesting (Score:4, Informative)

    by ijones ( 83977 ) on Thursday September 30, 2004 @07:20PM (#10400367)
    I like Subversion just fine as a "better CVS" but if you're looking for a better version control system altogether, I would look into distributed version control systems like arch [gnuarch.org], or if you're looking for something with a better learning curve, darcs [abridgegame.org] is really cool, and is implemented in the glorious Haskell programming language [haskell.org].

    Distributed systems like these have a lot of advantages over the CVS/SVN model.

  • How does it compare to Arch? (Score:4, Interesting)

    by caseih ( 160668 ) on Thursday September 30, 2004 @08:28PM (#10400718)
    I've considering selecting a new repository system in the near future. I need to support a web site, as well as programming projects. I read an article recently that quoted the creator of Arch as saying that Subversion sucked because it was designed wrong. Of course he neglected to give any evidence of this. For those that have used both, which ultimate was the better choice, if any?
    • I've tried both. Subversion is good as a drop-in replacement for CVS. Arch is probably better when you have distributed development. I use Arch most of the time, but the main problem with it is that it is pretty difficult to use at first, and that it uses rather strange file naming convention.

      Arch has the advantage of being very small and light. Your change data gets stored in simple .tar.gz files, so it's very easy to recover and backup if things go wrong.

      I can't comment on the supposed design problems w

    • Easy (Score:2)

      by lorcha ( 464930 )
      If you want to kill your brain cells writing code, use svn.

      If you want to kill your brain cells figuring out how to use your frickin' code repository and have no brain cells left for coding, use arch.

  • Cool (Score:4, Funny)

    by Dreadlord ( 671979 ) on Thursday September 30, 2004 @10:15PM (#10401218) Journal
    Cool, I'll download the latest version from the project's CVS ;)

  • What's with all the dependancies? (Score:3, Interesting)

    by rimu guy ( 665008 ) on Thursday September 30, 2004 @10:20PM (#10401235) Homepage

    There are over 30 subversion related packages in the install, including updated to db4, apr, httpd and mod_ssl. Moreover, it seems that (at least the last install I tried) these other packages must be updated as a pre-requisite for installing svn.

    I want to use svn+ssh. I don't need any of the apache/webdav integration. And having to move to a custom version of apache is going to be a show-stopper for a lot of people.

    And does anyone know why vanilla berkely db is not good enough for svn?

    svn developers: please release a client/server that can be installed without requiring updates to other packages (unless you need that specific, extra, functionality). Do this and you'll increase the svn adoption rate.

    --
    CVS & SVN Hosting [rimuhosting.com]

    • You don't need to install any special custom versions of anything for SVN. The only semi-unusual requirements are neon and apr. It works fine with vanilla Apache 2. You don't need to install Apache support if you don't want it, either -- I remember specifically choosing to install it.
      And vanilla berkdb is indeed 'good enough'.

  • Still no optional lock and merge tracking (Score:5, Interesting)

    by llopis ( 776294 ) on Thursday September 30, 2004 @10:20PM (#10401237) Homepage
    Optional locks and merge tracking are the two features that are holding Subversion back from being a real candidate for production code.

    I wrote about it here a few months ago http://www.gamesfromwithin.com/articles/0407/00002 6.html [gamesfromwithin.com].

    Fortunately, both those features are coming up soon by looking at Subversion's roadmap http://subversion.tigris.org/roadmap.html [tigris.org]

  • Nice new feature: (Score:3, Interesting)

    by captainclever ( 568610 ) <rj@NoSPAm.audioscrobbler.com> on Friday October 01, 2004 @02:38AM (#10402508) Homepage
    svn blame --verbose show extra annotation information
    Haha.. otherwise know as "Who the fuck broke this bit of code"? :)
  • I really hope they've changed the API around...damn.

    I swear, when I find out who decided to call every damn parameter in the entire damn thing a 'baton'.

    I hope they'll have a developer conference soon, I'll be bringing my 'baton' along.

Slashdot Top Deals

After all is said and done, a hell of a lot more is said than done.

Close