Oracle: Unbreak my Linux Heart

Want to move your legacy CVS repository into the next century but are afraid to loose information or damage your business-critical source code? Don't worry and please do as soon as you can! cvs2svn has released a new version. cvs2svn is a tool for migrating a CVS repository to Subversion, git, Bazaar, or Mercurial. The main design goals are robustness and 100% data preservation. Release 2.3.0 primarily improves the support for converting to git and Bazaar (including explicit cvs2git and cvs2bzr scripts). This release also adds a few other minor features and fixes a bug when converting to git with non-inline blobs.

TortoiseSVN : "A new version of TortoiseSVN is available: version 1.6.3, linked against Subversion 1.6.3. This is a bugfix/maintenance release only and includes many bugfixes in both TortoiseSVN and the svn library."

You may know that I've migrated from an RCS system to a Subversion (SVN) version control system. I migrated our RCS archive into a stand-alone, read-only, svn repository for reference purposes (using cvs2svn --use-rcs ) and copied all the files I personally needed into its own project folder in svnrepo/trunk/myproject. Since then I've been trying to get others to make the switch too. The other day, a colleague asked if I could transfer his files. He had kept using RCS after my import, so I tried to import his project into a separate folder off the main svnrepo trunk. I figured cvs2svn would let me set a destination directory. Well... it doesn't. I had a little discussion on the cvs2svn Mailing List . I thought it was my fault or ignorance. Turns out that you can't directly import a project into a specific svnrepo sub folder. And while it could be built, you have to realize something: The entire import would come chronologically after everything up to that point. All ta...

Today at work, a discussion was started relation to version control of code, tools, script and other files using IBM Rational ClearCase. I've just recently spent a lot of time digging my teeth into Subversion, so I was not amused. But corporate policy is policy, so what can you do? Well, it turns out: a lot . You may keep SVN, develop there and push releases into ClearCase. best of both worlds. CollabNet has a clearcase2svn connector . There is also a comparison of ClearCase vs. Subversion (PDF). And lot of discussions of people migrating back to SVN from ClearCase. LOL

Besides good ol' CVS and the de facto successor Subversion (SVN), the new invention and wide-spread use of distributed version control systems (DVCS) such as Mercurial, Bazaar and git (used for the Linux kernel itself) also have their advantages. For one, iBanjo says you can " suck down the entire history of a Subversion repository into a local, private repository, do all of your commits locally, make branches, experiment all you want, then “push” back up to Subversion again. For those interested in this functionality, there is now a very promising Mercurial to Subversion bridge called hgsubversion . Although still early, the bridge was done right and from the ground up using Subversion's own API and by someone with a good understanding of both svn and hg. The HOWTO is on iBanjo .

Found easy instructions on How to Mirror a Subversion Repository . I'm currently using svnadmin dump to regularly dump the repositories, but eventually I'd like to hotcopy everything over to a mirror that is in stand-by mode. The latter also copies hooks and configs, so that's useful as well.

If you manage a few dozen servers or more, maintain a couple of applications or even websites, you owe it yourself to use some kind of Version Control Systems . Something like CVS, SVN or maybe even Git. Alternatively, you can use something like cfEngine to keep all servers configured similarly. However, CVS or SVN can store working versions of all important in one place and provide you will roll-backs if worse comes to worst. Application servers create little config files like crazy and getting a release frozen into SVN, using a subversion tag, can be a life saver at times.

Now that I've been reading up on the use of Subversion (SVN) for SCM and version control, after testing CollabNet's subversion , their CEE integrated SCM toolbox as well the virtual appliance SFEE , I decided to go back to plain Subversion and set that up properly. That is, as far I can without much experience in daily administration, maintenance, etc. Getting ahead of myself, I briefly checked out Warehouse and Lighthouse which add resp. add a visual subversion browser and issue tracker. However, ViewVC does that and is bundled by CollabNet. Lighthouse is for later. However, I think I'll install svnLogBrowser , which let's you visually browse the SVN logs and inspect or monitor change logs. It's much handier than the command line tool and may help getting newbies up to speed.

Found a useful collection of Subversion Best Practices ... In addition, there is a more practical "getting started with subversion" guide organized in a "how do I" fashion . It also compares CVS commands to their SVN equivalent. Handy!

After a bit of stumbling around and getting confused using 2 versions of subversion, here is how I finally imported our entire RCS repository into Subversion from CollabNet. Prelude: I installed the RPMs from CollabNet as indicated in their readme and used the wizard to config 2 repository. Only thing I added, was to make all the repositories in /var/svn/repositories writable by the group csvn: chmod g+w /var/svn/repositories/* . That way the web server's user/group csvn:csvn can read and write in there. [root@server repositories]# ls -l total 12 drwxrwxr-x 7 csvn csvn 4096 Jun 18 17:54 repo1 drwxrwxr-x 7 csvn csvn 4096 Jun 18 17:54 repo2 [root@server repositories]# which svnadmin /opt/CollabNet_Subversion/bin/svnadmin [root@server repositories]# which cvs2svn /usr/bin/cvs2svn [root@server repositories]# cd [root@server ~]#cvs2svn -s /var/svn/repositories/io_se/ --use-rcs --default-eol=native RCS/ ----- pass 1 (CollectRevsPass) ----- Examining all CVS ',v' files... RCS/la...

Just a note, I'm still in the process of doing this... We decided to switch to a better way of doing SCM (Software Configuration Management) now that we've a major release and more and more people are starting to fiddle (aka mess) with scripts and files. We decided to use Subversion from CollabNet , as a natural successor to CVS. It could also provide corporate support, if needed, and has a nice SourceForge version with web-based GUI and all kinds of handy features. Also, our RCS repository seems to import well into Subversion. Bazaar and Mercurial also seemed to fit, but somehow I thought I would have a much harder time explaining them to the people working with it. The note, while using cvs2svn to import RCS into SVN (using cvs2svn -s /var/svn/repositories/rcs_import --existing-svnrepos --use-rcs RCS ), I ran into an error: " svn: Expected version '3' of repository; found version '5' ". This seems to be due to a schema change between subversion ve...

I've recently had to think about a good technical solution to our Source Code Management (SCM) problems. We're using a central RCS directory tree to handle everything. It started out with just a few scripts and kickstart files we needed to put under revision control , but soon it ballooned (or course)... While I do have some experience with CVS, I heard about Subversion (SVN) and other SCM tools and stumbled upon this comparison of Subversion or CVS, Bazaar or Mercurial . Great read! It doesn't offer a easy solution though, and experience is still the best guide. The difference between open and closed distributed revision control is also a tough decision to make, without solid team experience with either.