The JDS team never used TW since it simply didn't make sense when, at the
time, all of GNOME is using CVS, it just made sense for us to use the
same internally
since some sources would be internal, and others external, which would
allow us
to simply use one code management system.
Even in the CDE team which was firstly based in Ireland, and now China,
TW really was never
"friendly" to use due to it's reliance on NFS, which over a WAN link is
very slow given the
amount of file operations that resulted from a simple bringover or
putback. This probably
also had an influence on our move to CVS for JDS.
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.
The OpenOffice.org project also uses CVS as it's Code Management System,
for similar reasons.
SVN appears to be also gathering momentum as a replacement for CVS is
some circumstances - with
projects like Samba moving to SVN in recent times. There are pros and
cons to each, and if you use Google
you are sure to find some direct comparisons.
Your tools are certainly useful bridging the existing TW workspaces
internally, and enabling people who wish
to, to continue using it. But I think it's a little out side of the
scope of what code management
system to use for OpenSolaris - but certainly helps in pointing towards
CVS at the moment...
I don't know who has to make the final decision on this, but my vote
would be for one of CVS or SVN,
with a slight bias towards CVS.
Darren.
Nikolay Molchanov wrote:
I don't know if JDS sources have ever been under TW, or if JDS developers used
to use TW, but now decided to use CVS (which sounds strange to me :-).
Anyway, this is not a problem. We have created a TeamWare client for CVS.
This tool allows to use CVS repository as a "parent" workspace, so each
developer
is free to choose what model to use:
cvs checkout
edit files
cvs commit
or
cvsbridge cvs2ws
sccs edit
edit files
sccs delget
cvsbridge ws2cvs
This tool does not work with Subversion repository yet, but it should be easy
to teach it how to do checkout-checkin.
I think this is ideal solution to use TW-CVS and TW-SVN bridges. It allows
developers to use CVS or SVN directly (if they want to), but also allows to use
TW as CMS, using CVS and SVN repository as common "parent" workspace.
So the development process will look like:
- Sun developers continue to use putback to "commit" their changes.
- Every month (or every week, or every day, or every hour) these changes
are committed to CVS (and SVN) repository through TW-CVS (TW-SVN) bridge.
- External developers use TW-CVS (TW-SVN) bridge to update their workspaces
If they prefer to use direct "cvs" or "svn" - that's ok.
- External developers can deliver changes as patches. Each patch is related to
a CVS (SVN) revision. This revision has a correspondent delta in SCCS history,
which makes it easy to apply to this file.
- If external developers use TW, they can deliver SCCS files, and these files
can be merged with existing SCCS history (there is a minor technical problem,
but any experienced TW user knows how to do it).
So, again, the main point in this solution is that if we use TW-CVS and TW-SVN
bridges, developers have freedom to use TW, or CVS, or SVN, and all changes
will be easy merged back. The existing TW-CVS bridge is a small java application,
and I think we can open its sources if necessary, and it should be easy to
modify
it to work with Subversion.
Thanks,
Nikolay
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
