Posts tagged with “”

Thinking in Subversion

I just spent more time than I should have needed to spend learning that svn revert is so not the same thing as git revert.

I had modified a page in my working copy while trying to track down and understand the nature of an error. Once I figured out what I needed, I wanted to get my working copy of that file back to where I started. Having been a Subversion user for so long, I immediately tried to revert those changes. Wrong. Then I tried git reset only to find that while it works on entire repositories, it doesn’t work on individual file paths. At a loss, I turned to Twitter and, once again, Twitter delivered.

Thanks to Ben Kutil and Brad Greenlee, I learned that git checkout is what I needed. That never even occurred to me and, honestly, I doubt I would have tried it even if it had occurred to me. I’d have assumed it would throw an error. In the git paradigm, of course, it makes perfect sense that no error is thrown, but I’m still ascending that learning curve. I’m still thinking in Subversion.

How I Use Subversion

Last night I gave a Subversion presentation for the Refresh Baltimore group. The presentation ended up being a bit more of an informal dialog due to time constraints, but that was actually great. I rather enjoy talking with people rather than at them, when appropriate. The audience seemed to be largely front end developers, but many were very new to source control in general and, of course, Subversion in particular.

After the meeting, I thought I’d write a bit about how I use source control within my workflow. It’s the personal experience that folks in the group – myself included – seemed most interested in. The terminology I’ll use will be Subversion-centric since that’s my tool of choice (for the moment), but the philosophies, methodologies and processes should be comfortably analogous to other versioning tools.

Read More »

Subversion or Git

There’s been a lot of ambient (and not so ambient) noise in the geeky corners where I often linger about Git. There seems to be some sort of mass exodus underway as folks indicate that they have, or are planning to, move away from Subversion for their source control needs and I have to admit that I’m feeling a little ignorant.

I haven’t used Git (yet?), but I’ve been doing some reading and I still don’t quite understand the infatuation. Don’t get me wrong, it looks like there are some nice features, but at what cost?

The key difference between the two systems seems to be the model itself. Where Subversion offers a centralized model, Git provides a decentralized model. At the risk of over simplification, this means that Git offers each developer their very own, fully autonomous copy of the entire repository. With Subversion, each developer has their own working copy, but commits changes to a single, central repository.

The arguments in favor of the decentralized approach, as I understand them, include:

Speed

Okay, I like speed. Since each developer has a local copy of the entire repository, fundamental actions like diff, commit, etc. are all local. That’s always going to be faster. Fast is good.

That said, server interaction with Subversion isn’t exactly excessive. Developers work in local working directories and only interact with the server in short bursts. I’ve never found myself thinking, “Great Scott, this is unbearably slow.” For me, at least, this seems like a fix for something that isn’t broken.

Smaller Space Requirement

A Subversion working directory contains two copies of the entire code base. One that is actually being worked on and another tucked away in the .svn directory. I remember reading somewhere that the Mozilla repository required ~12Gb of storage in Subversion and ~420Mb in Git.

This is a substantial difference, to be sure, but there’s a phrase that everyone in technology hears on a daily basis: storage is cheap. That can’t be a compelling argument for one problem and not for another, so I don’t think this difference is one that’s going to precipitate a switch all by itself.

Line Ending Conversion

This is an important factor for mixed environment teams. Evidently early versions of Git made no changes and more recent version handle the conversion automatically. That decisioning is manual with Subversion, but is spectacularly easy to do by making a simple change to ~/.subversion/config for each file extension impacted to specify the line ending desired:

*.sh = svn:eol-style=LF;

Other Concerns

In addition to the fact that none of the arguments presented in favor of Git are particularly compelling to me, at least not the way I understand them, I have a few other concerns about the decentralized model. Actually, they probably all roll up to a single concern – accountability.

Every project I’ve worked on requires some level of immediate or semi-immediate accountability. A project manager who needs to ensure that an appropriate amount of progress has been made against the project plan, a boss who needs to spot review code or maybe a continuous integration process that needs regular repository updates so that its not just rebuilding the same old thing.

It seems like the decentralization of the repository would hamper those efforts. Sure, it can be done, but it would have to be done with process.

I also wonder if, in a team environment, having too many people doing too much of their own thing for intervals that stretch too long would make effective merges all but impossible. It seems like it would.

Am I missing something? Are there additional benefits? Is there anything else I haven’t even mentioned that I should be considering? I’d love to hear from other source control users who have moved to Git from Subversion.

Trying SmartSVN Again

Although I’ve been here before, I decided to give SmartSVN another try. It’s the only one I wasn’t able to actually play with because I wasn’t even able to get it open. This time, though, I put in a little effort.

Instead of just downloading the application and assuming it would, or should, work, I decided to be sure I met the system requirements. The only requirement, as far as I can tell is a JRE of version 1.4.1 or higher.

$java -version java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237) Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

Requirement met…check. Application downloaded…check. Tarball extracted…check. Application opened…denied (supply your own sound effect, please).

Clearly others use this application. Some, probably, with great success and affection. Why can’t I? The only way I can get it to start is to Show Package Contents and then navigate to Contents > Resources > Java and double click smartsvn.jar. Argh. I can’t believe there’s not a better way.

I’m not even sure that opening the app that way offers full functionality. For example, I can’t find a way to simply connect to a repository and browse its content. I have to create some kind of project first. Even worse, I have to do so by connecting to an existing working directory or by checking out code from one of my existing repositories. At the moment, I want to do neither. I just want to connect and perform a little maintenance directly on the repository.

I guess it’s me and my command line for at least a little longer.

Deleting .svn Folders

From time to time, I find myself looking at a directory full of .svn folders that I need to delete for one reason or another. On the Mac it’s not really a problem. I’m reasonably well-versed in the art of the Shell, so it was a trivial matter to pass the results of a find through to rm:

rm -rf `find . -type d -name .svn`

On Windows, though, I’m not so well-versed. DOS isn’t the easiest beast to tame and I (quite intentionally) haven’t written a batch script in years. As an avid Cygwin user, I can just crack open a shell and use the syntax above, but I’m also a user of TortoiseSVN and tend to spend more time in Windows Explorer than I do in Cygwin. As such, I found the idea of having a Windows Explorer context menu option appealing. A little hunting and pecking turned up a bit of code that, with a little modification, does exactly what I need it to do.

For anyone that may also be interested:

  1. Copy the code below and paste it into your favorite text editor.
  2. Save the file as whatever-you-want.reg (the .reg is the important part).
  3. Double-click the .reg file you just created.
  4. Confirm that you want to update your registry.

It goes without saying, of course, that all of the usual registry backup admonitions apply here. Monkeying about in the registry can be dangerous.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\DeleteSVN]
@="Delete SVN Folders"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\DeleteSVN\command]
@="cmd.exe /c \"TITLE Removing SVN Folders in %1 && COLOR 9A && 
FOR /r \"%1\" %%f IN (.svn) DO RD /s /q \"%%f\" \""

Update 2/20/2008: When I published this, I neglected to include a screenshot to provide some visualization of how the context menu option is presented. A few folks have asked for it, so the image shown below is a cropped image highlighting the relevant section. For a complete look at my context menu, click the image. Windows Explorer context menu snippet

Notes:

  • The last line should be edited to be on a single line. It was split for legibility.
  • I’m running Windows XP. The first line may need to be changed for other Windows versions.

For what it’s worth, the OS X solution above can easily be adapted to a Finder context menu by employing Automator. I don’t spend much time in Finder so I haven’t bothered, but I have a number of other scripts that I’ve added to the Finder context menu.

← Earlier Posts Page 1 of 2