svn

Since "svn update" is a subset of "svn merge" you can use something like:

(Source: http://translocator.ws/2005/10/12/svn-update-dry-run)

The only downside is that 'svn merge' does not quite work like 'svn update' in the sense that you can not run 'svn merge' from outside the workspace. E.g. if I have several workspaces under /tmp/irakli: /tmp/irakli/one and /tmp/irakli/two, I can run:

whereas /tmp is not a workspace. We can not do the same with svn merge.

Imagine a situation: you accidentally "svn removed" an entire directory tree from SVN. If the tree contained uncommitted code you can restore it from the backup, but you also need to restore things that were in the SVN. You can approach it multiple ways, but arguably the cleanest way is to simply revert to the revision before the deletion.

How do you do that in Subversion? The answer to this is quite short, but not necessarily obvious, so following is the list of example commands:

svn co -N SVN_PARENT_URL  . 
svn copy SVN_URL@REV FOLDERNAME
(Add-in or modify here any files that were not committed, before deletion)
svn commit -m "restoring" FOLDERNAME

example:

svn co -N https://svn.ex.com/repo/project/parentfolder@7537 . 
svn copy https://svn.ex.com/repo/project/parentfolder/deletedfoldername@7537 deletedfoldername
(Add-in or modify here any files that were not committed, before deletion)
svn commit -m "restoring" deletedfoldername

Default CentOS 5.2 yum repositories are still on Sybversion 1.4.x branch, so if you need the latest Subversion client, you are out of luck... or not, if you read this blog post :) This quick tutorial will show you how to upgrade in less than 5 minutes.

We will use RPMForge repos for the upgrade.

• Download and install proper RPMForge repo RPM for your server architecture (64bit or 32bit) from RPMForge website.
• Edit /etc/yum.repos.d/rpmforge.repo and change enabled=1 to "0". We do not want this repo to be enabled by default, because an accidental "svn update" will update all your packages to bleeding-edge, test-quality versions. RPMForge has many experimental rpms.
• Run: yum --enablerepo=rpmforge check-update subversion and make sure the version of subversion you are looking for is available. It should show you something like:
  

Yeah, I know - CVS is an archaic mess and there's not a single reason in the entire world to be using it in 2009... except if you are a Drupal contributor and need to maintain a module (or contribute to one) on drupal.org. For reasons that are complicated and don't matter to this blog post, Drupal uses CVS and there's no word that it will switch to something decent like SVN (git users - stay quiet), any time soon.

Fine, but when you actively use a version control, you need to be able to quickly see modified files. Files that need to be added or committed to version control. If you use a GUI CVS client - fine, but I don't. I do most of my development on remote Linux servers and command-line is my only cvs tool. Now that can get tricky in many ways. One of the ways is 'cvs status' command.

For reasons that I will never understand, CVS authors decided to show status of all files when you run this command over a directory. Plus they show 5 lines of information for each file. In the end - you can't see anything, if you are just looking for the names of modified files. Classic case of "less is more" (by the way - fixed in SVN, the improved CVS).

To emulate the behaviour of "svn status" that just shows a list of modified and new files, I wrote a quick bash script that hopefully somebody else, unlucky enough to be stuck with CVS, may find useful, as well:

#!/bin/sh

patterns=( 
	'?' 
	'Locally Added'
	'Locally Modified' 
	)

for i in "${patterns[@]}"
do
  cvs -Q status -R . | grep -i "$i"
done

More often than we'd like to acknowledge we get a need to remove Subversion .svn files in the working copy.

This will do it:

Linus Torvalds recently gave a presentation at Google about a new source-control management (SCM) system he has authored and that is being actively maintained by an open-source community - Git.

If you are a happy user of Subversion, you should take a break right now and watch the video (if you are a "happy" user of CVS, you are hopeless), because it will change and broaden your thinking. Git is not just another version control, it is fundamentally different the way it works.

And it is better! But, how? Ask yourself some questions about your current SCM:

• Do you commit every day? Should you?
• Can you commit if you are offline?
• Do you use branches?
• Do you look forward to merging branches?
• Do you need to have guidelines about naming branches/tags?
• What if your SCM server's disk died?

Now imagine that you have a system where none of these questions give you a shiver. That would be Git.

There are several books about Subversion, some small some huge. Yet, none of them gives a 5 minute get-going guide. Most of the developers are seasoned CVS users, so we do not really need a tirade about version control - just get us going!

And (I can hardly stress this enough) we\'d really like Subversion to authenticate over SSH. Leave that "pasword db" (in essence - open text file) or Apache Module bullcrap, to somebody else. Neither do we need the WebDav for version control - thank you very  much, but no.

The last time I set up a SVN repository (accidentally - my first time, too) it took me looking through 4 different books and a week\'s work on and off. Today I needed to do it, again and I found out that I did not remember much of the last experience. Well, it did not take me a week, but still more than I would want to spend on it. Anyway, to save myself time, in the future and in hopes of this being useful for folks who don\'t want to read 4 books, here is how it is done, on Unix (Windows can get lost, as far as I care):