TortoiseSVN no longer remembers password

In my workplace, we've been plagued with this issue since switching from http to https (maybe a year ago). At least, I think that's when it started. Whatever the reason, TortoiseSVN constantly forgets my svn credentials. I want to get to the bottom of why.

Here is the interesting bit - it can't really be tortoise' fault, as it clearly still knows the password based on the following behavior:

After it prompts you for the password that you had it remembering (that you had told it to remember previously), if you hit cancel and try your commit again, it won't prompt and it will work. Clearly the credentials remain stored, but some client/server interaction causes it to fail to authenticate sometimes. This happens very frequently. Most of us don't even bother checking the box anymore. (which would be a better practice from a security standpoint, but we all have our faults)

The moving parts:

• Subversion 1.5.x Server
• Apache 2.x
  
• TortoiseSVN (1.5.x)
• Active Directory (our authentication is against our standard AD credentials)
• HTTPS

I am sure there is a solution out there. I will keep this post updated as I progress...

Windows file path FAIL

I'm going to take a break on testability to talk about file paths - specifically long file paths, and the care one must take when dealing with them on Windows.

Now, while quite a lot of technologies are involved in development, for me (right now), the most important to mention when dealing with files are: Java, Subversion, Windows, and Tortoise SVN. I'll throw in one more - the filesystem (NTFS).

Using the command line is part of my nature, so when I get into the office in the morning one of the first things I do is open up a command prompt and 'svn update' my working copy.

Imagine my surprise one day when I couldn't update, because Subversion claimed one of its .svn/... files was corrupt or missing. Cleanup didn't help - it wasn't actually a Subversion problem. It was a file path problem. The svn FAQ actually has great information on this.

Enter the windows API maxium file path limitation of 260 characters. What's annoying is that it isn't ALWAYS the limit, in fact the unicode version of the API has a much more flexible limit (thousands of characters). Why then, does Windows Explorer, even in Windows 7, still use the API that has the 260 character limit? *

I deal with this issue again and again. I generally don't create file paths this long, but it doesn't matter - because I work as part of a team. I think it's reasonable for people to have descriptive, rich naming for their stuff - I just wish it wasn't so painful. Once files are in version control, then build tools, installers, and all kinds of things MIGHT have an issue depending on where the files are checked out and what file API they use. It's just not an issue I should have to deal with.

I don't want to worry about long file paths - this is a simple request. Of course, simple problems for computers aren't always simple. In fact, they usually aren't, but the fact that the API exists but that it isn't already the defacto, default API used by Windows itself frustrates me.

I want to be clear - this isn't a limitation of NTFS, Java, or Subversion. They are all quite happy to deal with long filepaths. It's the Windows file API. It's just easier than normal to get into bad situations when you have tools that will very happily (as they should!) create and deal with long filepaths, only to have your operating system tell you the file doesn't exist or can't be accessed.

* Probably backwards compatibility

That's my rant for the day.

SSDs for developers - my experience so far

I'm sure a lot of people have read the Anandtech articles on Solid State Drives by now, and maybe even Joel Spolsky's story (the combination of the two is what convinced me, after all). Just how big of an impact will an SSD have on your day to day development performance? I can't answer the general case, but I can at least share my personal experience.

I've been using an 80GB Intel x25-m SSD for the last 4 months, and everything about my workflow is faster. The main tools I currently use daily: Eclipse, Maven, and Subversion, on Windows XP 64-bit.

building our full app with Maven (javac, lots of file copies, jar creation, and other related actions - a lot more than just compile):

500GB x 2 (RAID 1): 10 min 45 secs

80 GB SSD (after filling it up): 3 min 25 secs

full build w/o clean:

500GB x 2 (RAID 1): 8 min 32 secs

80 GB SSD (after filling it up): 1 min 42 secs

We're talking 3-4x faster, after the drive is full and at the reduced performance level it will remain at. If TRIM were present, this would be an even wider lead. Initially a full clean build took just under 2 minutes, as compared to 3 min 25 secs now.

Aside from rebooting to ensure nothing was cached and disabling antivirus scan, I took no special effort to make this a 'real' benchmark. It is only what I've observed, but is in no way scientific.

For Subversion I do not have any way to measure time, suffice to say - if you are familiar with opening a commit window in TortoiseSVN only to wait minutes while it calculates differences followed by finally listing your modified files, that is mostly a thing of a past with an SSD. 10-20 seconds is the usual max wait. For reference, this is on a 3GB workspace with 30,000 files. Note that the .svn directories double amt of files and size due to storing a 'pristine copy' of each file. The workspace, if exported, has 15,000 files.

Similarly with Eclipse, if refresh/clean/autocompile seemed to take a really long time - it is also a night and day difference on an SSD. Rarely am I waiting for Eclipse to finish now.

Having an SSD eliminates a lot of time I'd otherwise have to waste waiting for something to finish. I think they are a worthy investment, and they are getting cheaper every month. I bought mine only 4 months ago, and the price has dropped from $400 to $229 for an 80GB Intel SSD. There are also a lot of competitive drives in similar price ranges now.

Here are a couple of things to check when looking into an SSD:

Make sure your motherboard's SATA controller is modern enough and supports AHCI mode. The original, older machine I tried it in (it was a 3 1/2 to 4 yrs old Athlon X2) could not see the real benefits of the SSD. I think any Core 2 Duo/Quad or more recent motherboard will be fine.

Buy a drive with a firmware that supports TRIM, or from a vendor that has released a manual TRIM utility. I would not trust any vendor that promises to deliver TRIM firmware or a utility after-the-fact. I had the impression TRIM was coming with my drive, and it looks like I'm out of luck with my first gen Intel drive. Who knows what the timeline is for TRIM on the second gen Intel drives. I believe all recent drives w/ an Indillix controller are fine, and I believe OCZ is even working on a background-TRIM firmware that works in XP. (It will be some time before my work environment is Windows 7...). Also, if you are a non-windows user, pay special attention to the TRIM firmwares. I believe a lot of them may only support TRIM on NTFS.