So I’ve been trying off and on for two days now to upload about 150 MB of files into a new SVN repository on Unfuddle, which I’ve been using and loving for about 18 months now.  I had to create a new project and associated repository for security/authorization reasons.

The problem was, that every time I tried to do an SVN IMPORT into the new repository, it would crap out.  the Tortoise SVN progress indicator (shown below) would all of a sudden go down to 0 kBytes/s, and then I would get a “connection forcibly closed by remote host” exception from Unfuddle.

Grr.

So then I thought, “let’s try just the biggest files first.”  In my import directory I have a subdirectory called /Assemblies/ which contain a bunch of binaries that need to be referenced elsewhere. So I tried to SVN IMPORT just the /Assemblies/ directory.

Same problem.

For the hell of it, I decided to just import a source code subdirectory, containing a bunch of little .cs files – let’s call it /lib/ – AND IT WORKED.  Yay!

Then, back to the /Assemblies/ directory. – AND IT WORKED TOO.

I’m thinking to myself: “self, what the hell is going on?”  I know that there’s no such thing as “priming the pump” in HTTP, so it must have something to do with the fact that I had an empty repository and was trying to load large (multiple-MB) files at the start.  Adding the smaller files from the /lib/ directory must have done something to the state of my repository that allowed it to successfully deal with the larger files.

Moral: when dealing with a new repository in Unfuddle, import small files first, before you attempt to import large binaries.

Hope this helps someone else.

At Startup Weekend Seattle this past weekend, the team used Subversion for its source control needs.  It’s a robust, stable, and usable product.  I have zero complaints with it whatsoever – in isolation.

But today I’ve been wondering if the CVS/SVN locking model maybe is bad from a Continuous Integration perspective.  Here’s the scenario I’m thinking of:

Andy makes changes to two files:

• lib_component.cs
• frontend1.cs

Where the change to frontend1.cs depends on the changes to lib_component.cs.  Andy commits and everything is fine.

Then, Bobby makes changes to two files:

• lib_component.cs  // same file Andy just changed
• frontend2.cs

Again, Bobby’s front-end changes depend on the simultaneous change to lib_component.cs.

If SVN can’t resolve Bobby’s edit to the library component, then the CI build that follows Bobby’s checkin is going to fail.  Now, you could argue that it’s Bobby’s fault for not making sure to work from the latest version of lib_component.cs, but in a fast environment, with commits happening fast and furious, it may happen.

I suppose it depends on what percentage of times you’ll get stuck with a merge that Subversion can’t handle automatically.  In practice, this might be a low number.

My gut tells me that if we had CI up and running at Startup Weekend Seattle, it would have been sending broken build notification errors more often than it would have been sending success messages.

Am I way off base here with my thinking?