[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Distributed Subversion

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 10 Jun 2009 16:28:12 +0100

On Wed, Jun 10, 2009 at 10:37:28AM -0400, David Weintraub wrote:
> I looked at CVS, and realized it had severe problems: Branching was much
> trickier. In CVS, you had to branch all the files together where in
> ClearCase you branched files ona needed case-by-case basis. That took
> time. This forced everyone to work off of trunk. A dozen developers
> working all on the same codebase? That seemed like an absolute disaster.
> These people needed to be moved to ClearCase as quickly as possible!
> In my first week, I noticed something very strange: There were no problems
> with builds or with developers breaking the build. I knew the developers
> were changing the code, but why was everything running so smoothly?
> It took me a couple of weeks to realize what as happening. Since the
> developers all work on the same branch, they had to constantly think about
> how their work affected the other developers. They talked to each other
> about the changes they were making. They made their changes in small
> increments. They worked together and made sure everyone knew what was
> going on.
> This was a great relevation to me. By isolating the developers' work on
> separate branches, we isolated the developers from each other. They could
> work without worrying what their changes might do to their fellow
> developers. They no longer needed to talk to each other.

I think that's part of why BSD systems are so developer-friendly
and stable. BSD projects have historically managed their code in CVS.
All the code is in one place. Everyone has the same tree, minus
locally applied patches.
Every commit gets tested by everyone running current code on their
machines, and most developers do run current code on a daily basis.
If a commit breaks something on any system run by a contributing
member of the community (be it user or developer), it gets noticed.

OpenBSD will probably never switch away from CVS. They're even
re-implementing CVS from scratch.

FreeBSD has switched to Subversion, and it looks like they are
happy with it.

DragonFlyBSD took the interesting route of switching to git.
Skimming their mailing lists, they still seem to be getting used
to it -- you can see gods like Matt Dillon complaining that a merge
doesn't work, and the author of the branch to be merged explaining
in detail all the git-foo magic that's needed to get it to merge cleanly
anyway :) It will be interesting to see how "distributed" they
eventually dare to get with git -- will they stop running code from
the same tree on all their machines, and what will the impact of
this be on the overall stability and maintainability of the system?

> A better mechanism for remote sites with slow access would be proxy
> repositories that constantly synchronize with each other. Subversion
> doesn't have a built in mechanism to do this. Yes, it is very possible to
> do with a little hacking, but Subversion wasn't meant for this type of
> setup.

Well, there are write-through proxies.

And there are commercial solutions that go a bit further.
And there is SVK.

> However, it is something that could be easily added onto Subversion
> without making major changes in its architecture.

Which is what SVK does.

Stefan
Received on 2009-06-10 17:29:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.