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."
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.
,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 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.
CVS was good enough for my company until we learned how SVN was able to make many things much easier. We did fresh imports of all of our projects into SVN. So we lost history in the new repository but kept around the old CVS repository just in case we needed its history.
That was a few years ago and we're far more productive today, especially with branching and merging.
Developers: We can use your help.
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.
I'm not talking about usability by power users; I'm talking about usability by idiots. Think Windows, not vi; both of those are very usable, but by two different groups of people. Compared to git, svn has a comparatively simple set of concepts which need to be grasped by its userbase. Yes, the WC library is horrid, and has all kinds of nasty gotchas that hit command line users -- particularly around renames, but your average idiot is coming from CVS (if anything at all) and doesn't expect renames to work anyhow.
I agree that svn is a POS. I've always thought that, and if you look back a bit in my posting history you'll see it confirmed; however, in a commercial environment it's often an easier sell than git.
``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.
Please correct me if I got my facts wrong.
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 the same workflow, it's not a necessary function to work with Git.
The authorative repository is the only one releases will be made from, though since everyone's working repositories are on network drives they are all backed up nightly. Then if they are working offline, they just clone their personal working repository to a local drive. I really like that I can pick and choose which repositories to merge based on the fix or feature, and have the developer working on those branches be able to pull from the authorative repository in the mean time to keep the branch from diverging too far. Maybe something similar can be done with SVN, but I really like how the Git paradigm fits, and even encourages, that workflow.