

Some Observations on Real World Software Development Life Cycle, pt. 1  - jackfoxy
http://jackfoxy.blogspot.com/2009/10/some-observations-on-real-world.html

======
makecheck
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>

~~~
jackfoxy
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
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.

