Slashdot Log In
Subversion 1.5.0 Released
Posted by
timothy
on Thu Jun 19, 2008 02:51 PM
from the sand-in-the-gastank dept.
from the sand-in-the-gastank dept.
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."
Related Stories
Submission: Subversion 1.5.0 Released by Anonymous Coward
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.
Is it me .... (Score:5, Funny)
As an Irish-American (Score:3, Funny)
Wait. What?
Upgrade breaks working copy compatibility (Score:5, Interesting)
Re:Upgrade breaks working copy compatibility (Score:5, Informative)
Subclipse 1.4.0, which works with Subversion 1.5.0 has been released [tigris.org]. 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 [google.com].
Those (along with the SVN commandline client) are probably the most popular clients, so most people won't need to wait "a while".
Parent
Re: (Score:2, Interesting)
Re: (Score:2)
Re:Upgrade breaks working copy compatibility (Score:4, Informative)
Absolutely not unusual. I use both the SVN command line client and TortoiseSVN's client on my windows boxes.
TSVN is great for working with individual files and doing the normal tasks of updating a single directory, or checking in files, or doing diffs, browsing the repository, or looking at change logs. Basically, we use TSVN for all of the interactive grunt work that goes on during our normal working day.
The SVN command line client, OTOH, is great for scripted things. Like running "svn update" on all of my working copies at 2am overnight - so that I have the latest changes from everyone else when I start working in the morning. If anyone added huge bulky files to the repository yesterday, they get downloaded overnight without my having to wait. And it speeds things up the next day so that when I use TSVN update, odds are good that I'll already have the latest revisions on my hard disk.
The change in working copy also happened when SVN went from 1.3 to 1.4 - so it's not a new issue. We all had to wait for our tools to be compatible with 1.4 back then as well. I think there were also changes on server-side back then, so if the server spoke 1.4, you had to use a 1.4 client. But you could leave the server at 1.3 and use 1.4 clients (backwards compatible), and then upgrade the server to 1.4 once you were done with client upgrades.
Parent
Re: (Score:2)
Re: (Score:2)
You might be dual booting between different Linux installations and sharing your
Re: (Score:2)
Re:Upgrade breaks working copy compatibility (Score:5, Informative)
Parent
Re: (Score:2)
Subversion is excellent! (Score:3)
I've been using subversion since it first came out and I must say it is really easy to use and a dream compared to some of the commercial offerings I have to fight with.
Thanks for all the hard work...
#1 svn feature is, and has always been... (Score:3)
...TortoiseSVN (yes, I know it's not technically part of svn). Makes version-control accessible to pretty much anyone who can operate a mouse.
I'd love to move to git or mercurial or similar, but frankly Tortoise outweighs all that distributed goodness.
Re:3, 2, 1 (Score:5, Funny)
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.
Parent
Re:3, 2, 1 (Score:5, Funny)
Parent
Re:3, 2, 1 (Score:5, Funny)
Parent
Re:3, 2, 1 (Score:5, Funny)
Parent
Re:3, 2, 1 (Score:5, Funny)
Parent
Re:3, 2, 1 (Score:5, Funny)
Parent
Re:3, 2, 1 (Score:5, Funny)
Parent
Re: (Score:2)
I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it just for some newer system. In fact, it's partially behind the
Re:3, 2, 1 (Score:5, Interesting)
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
If you're legitimately concerned about your data, you'll get off of CVS at the first opportunity.
Parent
Re: (Score:2)
This is the one thing that really annoys me about subversion - it is seriously missing some key bookkeeping here. Yes, I know there are scripts that hack it in, but that's not the same as doing it right in the first place.
Re:3, 2, 1 (Score:5, Informative)
Parent
Re: (Score:2, Insightful)
I note the preliminary merge support with interest, because we use svn at work (and I'm encouraging conversion to git) and having svn's metadata showing merging some of our branches will help with the conversion to git.
Re:3, 2, 1 (Score:4, Insightful)
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.
Parent
Bazaar looks good. (Score:3, Insightful)
Things I noticed:
Bazaar developers are very good writers. They explain things very well.
A lot of things they say [bazaar-vcs.org] make good sense to me. (Bazaar versus Git)
Re: (Score:2)
I never got the (recent?) craze over using the latest SCM of the week myself.
Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.
If one system works good enough for you right now, why switch?
True. But what if it sucks, why keep telling yourself that it is really great? Because that's the problem with CVS: it really isn't all that great.
I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it just for some newer system. In fact, it's partially behind the motivation to develop OpenCVS....
Oh well, if *Theo* said that then it is ok...
Re: (Score:2)
It was more of a response to the parent, than the article. I use SVN myself for a few projects... even started off a new repository on SVN.
> True. But what if it sucks, why keep telling yourself that it is really great? Because that's the problem with CVS: it really isn't all that great.
I never said to keep telling {my|your}self that CVS is really great, but I said *if it's good enough*. Unless there's really a mission-critical
Re: (Score:2)
Just one minor point of note, at least for our experience. It may be 8 years old, but it really wasn't suitable for our use until 1.3 (and we waited until 1.4 was done to actually do our rollout).
We wanted to use it earlier (started looking at it back in the pre-1.0 days), but we didn't switch until 2006. Shortly after the 1.4 release.
Re:3, 2, 1 (Score:5, Interesting)
That was a few years ago and we're far more productive today, especially with branching and merging.
Parent
Re:3, 2, 1 (Score:5, Insightful)
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.
Parent
Re: (Score:2)
But after a trip away without an internet connection I realised that not being able to take the repository with me and then handle merges when I got back was a bit of a limitation. Git looks interesting because it would get around this issue... but I just spent some time hacki
Re:3, 2, 1 (Score:4, Informative)
There's also Mercurial [wikipedia.org], which maintains a command syntax similar to Subversion, but uses distributed repositories. With it one can easily create a local repository suitable for offline use, including access to the full project history.
Parent
Re: (Score:2)
But for us, we don't currently place a high value on distributed and decentralized. Mostly because it's easier to be constantly connected then it was 5 years ago, but also because our users are not especially technically inclined.
Getting them to understand update/check-in and keeping their local disk in sync with the server is challenging enough (even with TortoiseSVN).
The other strong selling point for us is the broad adoptio
Re: (Score:2)
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.
Having not used git before, I don't really see what's so great about that. Suppose that your code is in svn in branches/devel. You could do a nightly svn cp branches/devel branches/`date +%Y-%m-%d` to track all your revisions locally. You can do diffs between branches, delete them, rename them, etc.
Again, I've not used git. What would it do better? Help me see the light.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
We've only been using SVN for the last 8 months, so switching SCM's is not a huge ordeal right now. To be honest I'm quite happy with Git so far. There's only a handful of developers at my company so we don't have time to become experts with any tool, and as far as basic features goes, Git works in a way which fits our development paradigm better.
To be fair, with different requirements I'd use Subversion again in a second.
Re: (Score:3, Informative)
I'll add to your post a point that is often missed, so it bears repeating:
Just because git _allows_ you to do distributed development (multiple repositories) doesn't mean you _can't_ have a single main repository. There can still be one "blessed" version of the code, which is backed up and everything else you like to do with your Subversion repository.
However, if you ever want to make a couple of commits while disconnected from the network, or try something out, making multiple commits along the way, until
Re: (Score:3, Interesting)
I avoided calling it a Central Repository in all the training materials I prepared for my coworkers, instead I called it the Authorative Repository. Only a small subset of us have write access to it, so no one can push any branches to it. Instead, approved changes must be pulled to it by myself or the other maintainer, but everyone can read from it if they want to create a remote tracking branch or pull from it. Push was only implemented to allow those familiar with a central repository paradigm to keep
Re:3, 2, 1 (Score:5, Insightful)
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)
Parent
Does [git/hg/bzr/etc] write my code yet? (Score:4, Interesting)
No.
I started out in version control with SCCS. I used the first generation of ClearCase when it came out. (Still the most transparent system yet devised, a dream to use for an individual developer, crippled by inability to scale, admin complexity, and absurd cost).
The fact of the matter is that CVS works. My current project has > 500K lines of code in CVS, and we sell product. We don't like CVS, we're planning to move to SVN, but the fact of the matter is that we don't *have* to. To me, the source control system is more or less like the file system : I need it to the extent that my work is in there, but other than that I don't want to see it or even know it's there. People drool over git and mercurial like these things are -doing work-. I don't get it and I don't buy it. The fact of the matter is, that unlike say a compiler, the SCM system has ZERO effect on the end product.
So I get the advantages -for some projects-, esp. large open source or distributed commercial projects, of a natively distributed SCM system. I don't get how SVN is now inferior and lame because it isn't distributed.
Parent
Re: (Score:3, Insightful)
In every organization I've worked in, developers have to manage source. Their own source, third-party source (whether OSS, vendor code, drops from another team, etc.) I.e. their work involves more than just blindly pounding out code. The new tools really do reduce the amount of time spent screwing around with the SCM system instead of doing other things. Even really basic stuff like just having more intelligent history-based merging algorithms can save staggering amounts of time.
Re:Does [git/hg/bzr/etc] write my code yet? (Score:5, 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.
Parent
Re:Does [git/hg/bzr/etc] write my code yet? (Score:4, Informative)
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
Furthermore, this second copy is stored in the same folder tree, which is both annoying (from a tools pov, like grep) and slow (OS has to stat a lot more inodes).
Parent
Re: (Score:3, Informative)
SVN works fine with large trees (whether that's measured as # of revisions, # of files, or # of bytes).
Yes, the working copy stores a "pristine" copy in the
Re:3, 2, 1 (Score:4, Informative)
You're painting this far too black and white.
Distributed systems have their own set of limitations, some of which centralized tools don't have. Some development processes cannot be implemented with distributed tools, pretty much the same way as processes such as how the Linux kernel is developed cannot be implemented by centralized tools.
For example:
Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk", first, and is then applied to release branches if necessary. This makes sure that I have one common place to log all changes ever entering my code base. That's very simple requirement, right? This approach is used by many projects, e.g. by all the BSDs, and by Subversion itself. Let's say I picked Mercurial as my tool for the job.
So I have a changeset on my trunk, and I want to merge it into my 1.x and my 2.x release branches. I will first need to pull the change from trunk into my branch, right?
Wait... why does it say "up to which"? I just want that one change!
Darn, turns out that in Mercurial, changesets depend on all their ancestors in order to guarantee integrity of all changes I pull from another clone of my repo. You cannot pull a change without having around its parent, since revisions are identified by hashes in order to be globally unique across all clones. The hash of a revision is derived partly from the hashes of its parent revisions (they are included in the manifest).
So I need all parent revisions of my changeset in my branch. Since I've forked off my branch from trunk, and have not yet made changes to the branch itself (remember that all changes to the branch should be coming in via trunk), Mercurial will see no conflicting heads and simply forward my release branch to the latest head of trunk. So I can either pull every change I've made on trunk since forking the release branch (not much point in that), or manually apply a patch to the release branch (i.e. side-step the tool).
Well, great. With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk to a release branch is
So in practice, people using Mercurial end up fixing problems on their release branches, and merge the fixes to their main line later. And yes, it seems like you have to manually apply a fix to all your release branches separately (at least I haven't yet found another way).
In all fairness, there is in fact an extension that allows Mercurial to "transplant" a changeset from one branch to another without requiring you to also merge all the parents of the changeset: http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension [selenic.com]
This extension maintains a special file mapping local changeset hashes to remote ones. You have to bet your luck on not ever creating the same hash for two different revisions, though, otherwise your project's history is borked (I have no idea how likely this is).
Certainly, maintaining a separate list of changeset ids is not something intended in the original design, which focused on providing distributed branching and merging. The design does a very good job at this no doubt. By making sure that all bran
Parent
Re:3, 2, 1 (Score:4, Interesting)
``I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it''
It may be good enough for them, but it's not good enough for me. I don't want to spend half a day upgrading my ports collection through CVS if it's quicker for me to just download the new tarball.
``I never got the (recent?) craze over using the latest SCM of the week''
I think it is recent mainly because Subversion has broken the hegemony of CVS. Of course there is much inertia to switch, and that is a Good Thing. Subversion, however, is easy to pick up and so much better that it actually displaced CVS as the Version Control System Everyone Uses (TM). Inspired by the success of Subversion, everyone with the inclination and a large enough ego started their own "better than CVS" version control system. Some of them are horrible, some of them are shiny commercial crap, some of them are better in theory, but lacking in implementation, and some are actually better. My personal favorite is Git. It works well, is easy to pick up if you already know CVS or Subversion, has a couple of desireable features, and, last but not least, it's FAST. Of course, many people will stick with Subversion, CVS, or whatever Microsoft integrates with their other software.
Parent