Slashdot Mirror


Subversion 1.5.0 Released

Hyrum writes "The Subversion team is proud to announce the release of Subversion 1.5.0, a popular open source version control system. The first new feature release of Subversion in almost 2 years, 1.5.0 contains a number of new improvements and features. A detailed list of changes can be found in the release notes. Among the major new features included in this release is merge tracking—Subversion now keeps track of what changes have been merged where. Source code is available immediately, with various other packages available soon."

5 of 104 comments (clear)

  1. Re:3, 2, 1 by nonsequitor · · Score: 5, Insightful

    I'm in the process of migrating my department from Subversion to Git for a single very compelling reason. Distributed Development.

    I work in the Maritime Industry and frequently have to change software on the fly during Sea Trials. With SVN, revision control while on a boat is impossible since while offline, there is no access to the central repository to check in revisions. Now with Git, I can continue to work productively offline and seamlessly push the day's changes and revision history to a repository on the network drive for nightly backup when returning to the office.

    I realize not everyone has the requirements I do for source control, but everyone should pick the SCM Tool which best meets their organization's or personal requirements. Having a working familiarity with several tools is necessary to make an informed decision.

  2. Re:3, 2, 1 by John+Whitley · · Score: 5, Insightful

    I never got the (recent?) craze over using the latest SCM of the week myself. For those of us who really understand SCM systems, and are heavy users of same, the desire is to get a handle on the capabilities of the new generation systems. The reason is simple: CVS utterly sucks, and SVN wasn't a revolutionary improvement. Simple high-level tasks in a real working environment (e.g. tracking upstream branches against local changes) are frequently a time-consuming pain. Many collaboration use cases (e.g. developer/feature branches) are similarly a hassle to manage. SVN at least gave folks atomic commits, which was a huge step.

    My guess is that SVN will turn out to be too little, too late with its merge tracking support. It'll be a boost for folks already using SVN who don't want to switch toolchains, but it's pretty easy to move from SVN to the new tools (beyond export, several newer SCMs have two-way commit support with SVN).

    Generationally speaking, it feels like SVN is still trying to catch up to Perforce... but that ship has sailed. The teams working on the new round of decentralized SCMs[*] have done deep rethinking of source control problems and challenges, and the results are generally brilliant. These problems aren't esoteric -- administration and day-to-day usage really is easier with the new stuff. After a while using git, Bazaar, etc., the crufty old SCM tools seem like doing image editing in a hex editor instead of a GUI app.

    [*] Includes: Bazaar, Darcs, git, and Mercurial (hg)
  3. Re:3, 2, 1 by R_Dorothy · · Score: 3, Insightful

    You don't have to do a nightly svn cp branches/devel branches/`date +%Y-%m-%d` to track all your revisions locally.

    Seriously though, each working copy is a fully functional repository with complete history able to merge changes from other working copies (which are also fully functional repositories etc.)

    It also doesn't need a full server infrastructure. I've started using local, stand alone, git repositories to track config files.

    --
    Stupid flounders!
  4. Re:3, 2, 1 by cduffy · · Score: 3, Insightful

    I agree with you that this is too little, too late. That said, there's one respect where Git is well behind: Usability.

    svn and bzr both have it beat -- hard -- in that respect; particularly svn, which has more pervasive tool support (but plenty of other disadvantages). That does little good, though, when you're picking a tool for use on a large project including artists, tech writers, win32 GUI developers, and other folks who have less of the appropriate inclinations.

    I say this as someone using git on a daily basis. It's not a bad tool, but an end-all be-all it's not; for my own projects, I use bazaar.

  5. Re:Does [git/hg/bzr/etc] write my code yet? by RAMMS+EIN · · Score: 4, Insightful

    ``People drool over git and mercurial like these things are -doing work-.''

    But they do. They keep track of what changed, when it changed, what else changed at the same time, how the change was justified, and who changed it, and, very importantly, how things were before the change.

    The choice you have is between having this information and not having it, and between various interfaces to the information.

    That's as far as the work they do for you is concerned.

    On the other side of the balance, you get to choose your limitations and performance impact.

    Of the major systems, I find that CVS has both the lowest performance and the worst limitations, Subversion does acceptably on both counts, and Git has great performance and flexibility.

    To sum it up, version control systems _do_ actually do work for you, and there are noticeable differences between them that make choosing wisely worthwhile.

    --
    Please correct me if I got my facts wrong.