It's the latest and greatest SVN as of August, (can't recall what release that is). Branching is instantaneous, which is faster than TFS. Where it slows us dow

It's the latest and greatest SVN as of August, (can't recall what release that is). Branching is instantaneous, which is faster than TFS. Where it slows us down is iterfacing with the trunk (primarily updates to the local working copy). Because our application is huge and highly integrated a whole lot of source files exist in one repository. Under TFS the repository knows what is going on with every client working copy. SVN is ignorant of working copies.All of the interaction between repository and working copy consists of doing "stuff" on two files systems, rather than doing it in the "brain" of a SQL server. I've got a much smaller SVN implementation that executes updates and commits much faster. It only makes sense the file based approach will start slowing down at some scale. Merging has not been an issue for us, once we got used to how it works. It's a sister organization of ours under the same corporate umbrella that can't figure it out, and I suspect that has more to do with their internal processes than SVN.