Tortoise SVN - Update Failed! - Adapting an SSIS development approach for Window Server 2008

Trained some new developers on a SQL Server BI solution that required them to edit various source files - including SQL Server Integration Services (SSIS) packages.  Well immediate after the orientation to the Version Control repository a new developer received an error attempting to update the local repository.

Turned out a couple of assumptions or constraints were in play

1.       Development of SQL Server Integration Services packages is easier from a server console.  The connection rules aren't an issue.  The connection to source systems is usually - not always - but usually faster.  Running a long-running package doesn't interfere with the developer's ability to do other programs on their laptop… or close it up and go home while the long-running process churns on.

2.       Using TortoiseSVN to edit-merge-commit from a remote repository running on a file server was a simple and elegant version control approach.

3.       Having the source code on a shared folder on the server's local file system was convenient

4.       When there were two developers and a Server running Windows Server 2003, this generally wasn't a problem - we weren’t stepping on each other's folders and/or 2003 security was fairly lenient.

After migrating this technique to Windows Server 2008, these error became apparent quickly.

1.       It was still convenient to develop SSIS packages from the server's console.

2.       The shared folder on the local file system became problematic.  The 2008 security (it behaves like Windows Vista or Windows 7 does) became more finicky about file ownership and ability to edit and delete files with another's ownership.

3.       Multiple developers currently in edit or merge, but not yet commit steps would collide with each other if one another's work overlapped in the file system.

The solution I took was to have each developer create their own 'SourceCode' folder under their 'Documents' folder (i.e. C:\Users\%USERNAME%\Documents\SourceCode). 

Tradeoffs are it is a bit trickier location to which to navigate.  And the redundant copies of the code for multiple developers have a minimal impact on storage.  The advantage, of course, is a truer work process with SVN - each developer is forced to develop SSIS packages separately editing and merging; mitigating most conflicts through collaboration.