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."
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.
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)
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!
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.
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.
Right, because remembering a bunch of svn:properties is so easy. Figuring out why subversion memory faults when given both a file and url path is so user friendly. Or why you can't use a subversion folder through a symbolic link. Or why there are .svn folder everywhere, or if they are hidden why you can't remove an empty folder. etc. svn is a piece of junk and especially from usability pov.
In this release they made it so you can mark a subfolder so it doesn't update automatically. That's like two lines of code.... noup = get_property(curpath, "noupdate"); if (matches(noup, "nosubfolder")) return; That's the big progress they've made on the file layout which they've known for years is retarded ?!
In mercurial or git people submit patches for this kind of thing all the time, because it's in python or scripts and easy to change. Svn is over-engineered and so inflexible that it is being left behind.
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.
``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.
Wow! I just looked at Bazaar.
Things I noticed:
Bazaar developers are very good writers. They explain things very well.
A lot of things they say make good sense to me. (Bazaar versus Git)