>On Thu, 2005-07-07 at 09:44, Darren Kenny wrote: >> CVS and SVN were designed with globally spread out developers in mind - >> TW wasn't. I think >> this is what makes them stronger candidates as a code management system >> for OpenSolaris.
Teamware was very much made for distributed developers; but not in the sense CVS works. At Sun we run many projects in many parts of the world in cloned workspaces; this is a model that has worked reasonably well for us, but some tools are used to ease the pain for remote developers. The fact that developers all write to the main repository for their branches even when nowehere near completion just doesn't make sense to me. Either way you have to continuously merge the main branch with your own branch, so there's no gain to be had there. I think that what you're saying is really "CVS/SVN" where designed for globally spread developers *with a central active repository*. In the teamware model we use, the main branch only gets putbacks from finished work and so it's a straighline repository. >they still require developers to either have write access to the main >repository >and put all their files there or make a big mess with creating a new >repository for >local files and merging between them every now and then. Under teamware, merging is fairly automatic. >please consider the (slightly newer) crop of tools that support really >distributed >work, eg. arch/bazaar, monotone, svk (there are more comprehensive >lists, eg. >http://www.venge.net/monotone/others.html) svk is certainly under consideration as are other tools; I thin CVS is out because it's just too bnroken. >(summary of scenarios where distributed tools help and cvs|svn do not: > - managing integration branches of some sorts, eg. Solaris (vs. >opensolaris) > - helping those people on the plane or some island with slow net access >still work > reasonably fast, by having a local storage to put their changes in >instead of > waiting >1 minute for each commit - sync can happen later, after work >where waiting > is not an issue or when getting fast net access again. >) Our teamware model requires a synchronization step just prior to the putback. That is a bit of a drawback and has some issues with scalability (e.g., the last build open for non-critical bugfixes gets to be very busy) Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
