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

Comments

Is it me ....

[Archangel Michael]

or does anyone else find the FISA article and the Subversion article being sequential a tad ironic?

Re:3, 2, 1

[cp.tar]

Those flames are subversive to normal communication, not to mention monotonous. But now that you mentioned them, somebody will have to start one. What a git.

Re:3, 2, 1

[cduffy]

Part of the problem is that the conversion scripts coming from CVS have to make up some data that isn't in the repository, but which all newer SCMs track.

If you get yourself to something modern enough to support multi-file transactions, to recognize rename operations, to store merge history, and to manage branches in a reliable way (creating a file on a branch in CVS can also create that file in HEAD... or at least, it did last time I used CVS in production) future conversions won't be as necessarily painful and/or lossy.

CVS isn't even reliable in terms of storing history in such a way that you can guarantee that you haven't lost something; when I was maintainer of cscvs, I had several users having problems because their ,v files had gotten truncated somewhere way back; because that only impacted attempts to retrieve revisions prior to the truncation point, nobody noticed until their backups had already been fully rotated past that point. More modern SCMs have provisions in their data formats for validating repository validity, and even for checking changesets against deliberate tampering.

If you're legitimately concerned about your data, you'll get off of CVS at the first opportunity.

Re:3, 2, 1

[Anonymous Coed]

What a bazaar reply. Are you suffering from mercurial poisoning?

Upgrade breaks working copy compatibility

[againjj]

There is an important piece that is going to keep me from being able to use it for a while:

Before upgrading to 1.5.0, please take note of the following: * Due to various improvements made to the working copy library, the working copy format has changed. Using Subversion 1.5.0 on any working copy created by previous versions of Subversion will SILENTLY upgrade your working copy, which means that previous versions of Subversion will no longer be able to read it. I use multiple clients on my machine, and they all are going to need to be able to use 1.5 before any of them can.

Re:Upgrade breaks working copy compatibility

[Dahan]

There is an important piece that is going to keep me from being able to use it for a while

Subclipse 1.4.0, which works with Subversion 1.5.0 has been released. TortoiseSVN release candidates that are compatible with SVN 1.5 have been out for a while, and the plan is to release TortoiseSVN 1.5.0 this weekend.

Those (along with the SVN commandline client) are probably the most popular clients, so most people won't need to wait "a while".

Re:3, 2, 1

[nonsequitor]

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.

Re:3, 2, 1

[John Whitley]

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)

Re:3, 2, 1

[cduffy]

Subversion stores merge history?

As of 1.5, yes. That's one of the Big Features for this release.

Re:3, 2, 1

[Scullywag]

This is a clearcase of a thread going out of control.