5 ms·

Is this svn 1.5+? Branch/merge is a lot easier with 1.5's enhancements; I'd guess that most horror stories with merging are when using older versions. As far

Is this svn 1.5+? Branch/merge is a lot easier with 1.5's enhancements; I'd guess that most horror stories with merging are when using older versions. As far as having the whole world in one repository, I'd just avoid it, and not just because of svn's performance in deep directory structures. Surely there are logical parts of the whole that could be separately maintained? Also look at svn's externals[1], to allow a repository to virtually contain parts of other repositories. The trick is that links must sometimes be tweaked; for instance, if you make a branch and do not want to continue to depend on the trunks of your dependencies, then you must reassign externals. [1] http://svnbook.red-bean.com/en/1.0/ch07s03.html http://svnbook.red-bean.com/en/1.0/ch07s03.html

jackfoxy 17y ago
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.
- jackfoxy 17y ago
  BTW, we'd have to re-architect to avoid the whole world in one repository. And even if we could figure out a clever way to do it, it would likely present organizational complexities.

jackfoxy 17y ago

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.

jackfoxy 17y ago
BTW, we'd have to re-architect to avoid the whole world in one repository. And even if we could figure out a clever way to do it, it would likely present organizational complexities.