Tag: Subversion

Uninstall Subversive

Although Subversive is the official Eclipse Subversion provider, the plugin itself doesn’t behave very well. In particular, it is impossible to uninstall it (v0.7) using the “Software Updates” dialog. The only option is to delete the jar files yourself (in 2001 I remember hoping that soon, we wouldn’t have to do stuff like this). Here are the files to delete:

(Disclaimer: this worked for me, I make no promises for what it might do to your Eclipse installation) 

org.eclipse.team.svn.core_0.7.5.I20081029-1900.jar
org.eclipse.team.svn.help_0.7.5.I20081029-1900.jar
org.eclipse.team.svn.resource.ignore.rules.jdt_0.7.5.I20081029-1900.jar
org.eclipse.team.svn.ui_0.7.5.I20081029-1900.jar
org.eclipse.team.svn_0.7.5.I20081029-1900.jar
org.polarion.eclipse.team.svn.connector.javahl15_2.0.5.I20081024-1200.jar
org.polarion.eclipse.team.svn.connector.javahl_2.0.5.I20081024-1200.jar
org.polarion.eclipse.team.svn.connector.svnkit15_2.0.5.I20081024-1200.jar
org.polarion.eclipse.team.svn.connector.svnkit_2.0.5.I20081024-1200.jar
org.polarion.eclipse.team.svn.connector_2.0.5.I20081024-1200.jar

Remove .svn files recursively

Today I needed to convert a Subversion working copy (aka a checkout) into an export. Recursively blowing away all of the .svn directories in DOS (Windows XP) didn’t seem to be straightforward so I ended up using UNIX find in cygwin. Here is the command: 

find . -type d -name '.svn' -exec rm -rf {} \;

The command was provided here, and the following is documentation from the man page.

  • find :: Execute the find command
  • . :: Path in which to start
  • -type d :: File is of type ’d’, a directory.
  • -name ’.svn’ :: The file name on which to match, .svn.
  • -exec rm -rf {} \; :: Execute this command for every file that is found. The string ’{}’ is replaced by the current file name being processed. The semi-colon is escaped by a backslash. While reading the man page, I also found that you probably should enclose the braces in single quote marks.

What every Subversion user must know about Git

Subversion is perfect (simple concept, lots of books, good tool integration, and easy to use) but for the fact that it doesn’t support:

While the former should be addressed in version 1.5, the latter is anyone’s guess.

The problem is that Subversion is just so good that eventually you will will want a distributed mode with Subversion.

Fortunately, Git supports distributed operation against Subversion repositories!

If this gets you “on the Git bus”, check out this:

An introduction to git-svn for Subversion/SVK users and deserters.

(Thanks Geoff for the links)

Addendum 05/03/08:

Tonight I tested out setting up cygwin from scratch to use Git, and in doing so confirmed what I knew and discovered what I didn’t!

You must use the following packages:

  1. Git 1.5.5.1-1
  2. Subversion 1.4.5-2
  3. Subversion-perl 1.4.5-2

Failure to install the subversion-perl bindings results in the error: = Can’t locate SVN/Core.pm in @INC

Thank you ycdtosa for the pointer!

Addendum 05/03/08:

If, like many of us, you haven’t fully cut over to cygwin, you may receive the following error message when you attempt a commit:

You have some suspicious patch lines=

Here is both an explanation of and a work-around for the error.

To solve the problem, you need to edit .git/hooks/pre-commit and comment out the following lines:

=if ($) { bad_line(“trailing whitespace”, $_); }=

Before tonight, I figured that I would never have the need to use dos2unix ever again! Based on one of the commentors replies, though, I expect that further research on the operation of Git is required on my part in order work between CR and CRLF environments:

Git from some time has core.autocrlf and crlf attribute, which should help in mixed UNIX (LF) and Windows (CR LF) environment

Just 3 little words

On my previous project, we had just a bang-up bunch of guys on the team. Everyone was smart, thoughtful, and worked well together: it was ideal. Since there was no revision control system in place when we arrived for the project, we decided to use Subversion. Since I had championed Subversion, I became both the Subversion system and repository administrator.

After a few months, and few thousand commits (a lot of them without any commit messages) I decided to add a commit hook script to prevent commits without comments. To be fair, I figured that no one would mind being required to write commit messages that were as long as they had already been writing, so I wrote a script to get the mean number of words in the commit messages (to date) that were not empty. The average was 7.

7 is a good number, at least enough to convey the “why” with enough brevity to make the RCS helpful. That said, I figured I would be even more accommodating of the users and require only a mere 3 words in every commit message. I made the change, tested it out, and deployed it to the Subversion server.

Eager to view the informative commit messages that would surely result from this new “feature”, the next day I took at look at the first commit message that followed the change:

“#!@& YOU GRANT”

Thanks guys, you gave me my favorite Subversion story.