head	1.4;
access;
symbols;
locks; strict;
comment	@# @;


1.4
date	2001.03.09.18.36.29;	author lori;	state dead;
branches;
next	1.3;

1.3
date	2001.02.11.18.29.47;	author jrobbins;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.09.00.59.20;	author susank;	state Exp;
branches;
next	1.1;

1.1
date	2001.01.29.19.44.19;	author lori;	state Exp;
branches;
next	;


desc
@@


1.4
log
@removing this file; extraneous
PR:
Obtained from:
Submitted by:
Reviewed by:
@
text
@<HTML>
<HEAD>

<TITLE>Project Source Administration for Project Owners</TITLE>

</HEAD>
<BODY>
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
<SPAN CLASS="HEADER">Project source administration for project owners</SPAN>
<P>
<SPAN CLASS="PlainText">
<UL>
<DL>
<DT><A HREF="#gettingstarted">Getting started</A>
<DT><A HREF="#siteadmincvs">CVS repository tasks handled by site administrators</A>
<DT><A HREF="#considerations">A few initial considerations for project owners</A>
	<DD><LI><A HREF="#definestructure">Starting from scratch</A>
	<DD><LI><A HREF="#postrcsissues">RCS vs CVS project management issues</A>
	<DD><LI><A HREF="#cvspermissions">Managing CVS permissions</A>
</DL>
</UL>
<P>
<A HREF="gettingstarted"></A><SPAN CLASS="InputHeader">Getting started</SPAN>
<P>
If you are new to CVS, this help guide provides some basic quick reference information for administrative CVS tasks relevant to projects hosted this site. This guide by no means exhaustively documents CVS or the many broader project management issues imputed by versioning control. A wealth of published documentation for CVS exists, both online and in print. The following links lead to general CVS information elsewhere on this site, and these documents include many authoritative, external CVS resources.
<P>
<UL>
<LI><A HREF="ddCVS.html">About CVS source code version control</A>
<LI><A HREF="ddCVS_cvsprimer.html">A CVS primer: basic concepts</A>
<LI><A HREF="ddCVS_UsingCVS_command-line.html">Using command-line CVS to work with project source files</A>
<LI><A HREF="cvscontributing.html">Contributing changes with command-line CVS</A>
</UL>
<P>
<A NAME="siteadmincvs"></A><span class="InputHeader">CVS repository tasks handled by site administrators</SPAN>
<P>
Much of the administrative work involved with setting up your project's source repository is handled "behind the scenes" when your project gains approval. In other words, because your project is hosted on this site, you do not have to start from scratch to configure CVS for your project. The following tasks occur automatically:
<P>
<UL>
<LI>Your project's basic repository structure is created with a top-level directory that can be expanded upon by adding subdirectories  as the project evolves.
<P>
<LI>Your project's CVS root (that is, the server where your CVS repository is located) is automatically set to this site's host servers and preconfigured. You can find this information by ... <!-- ADD INFO -->
<P>
<LI>Files in the CVS administrative module are preconfigured for projects hosted on this site. Those include the following, listed here for your information:
<P>
<UL>
<LI>Modules file
<LI>Cvswrappers file
<LI>Commit support files
<LI>Commitinfo
<LI>Verifying log messages
<LI>Editinfo
<LI>Loginfo
<LI>Rcsinfo
<LI>Ignoring files via cvsignore
<LI>Checkoutlist file
<LI>History file
<LI>Expansions in administrative files
<P>
</UL>
All CVS repository tasks such as backing up, restoring, moving, or configuring remote repository access are also handled by this site' administrators. Should your project requirements necessitate editing CVS administrative files or conducting repository-level actions, you must contact a site administrator for support.
</UL>
<P>
 
<A NAME="considerations"></A><SPAN CLASS="InputHeader">A few initial considerations for project owners</SPAN>
<P>
<A NAME="definestructure"></A><B>Starting from scratch</B>
<P>
When your project is completely new or still in infancy, plan the overall directory structure at the front end of project evolution. Although the top level CVS module structure is predetermined, decide how you generally want to organize source files so that you can communicate this to existing and potential contributors. Considering source structure early on enables you to maintain consistency as the project grows, and makes it easier for new contributors to get up to speed.
<P>
A good example of communicating overall project source structure is in the <A HREF="http://scarab.tigris.org/scarab-design.html#directory" target="_new">design document for the scarab open source project</A> which uses a graphic depiction. CVSWeb source browsing, provided with all projects hosted on this site, also allows users to explore your project's source structure.
<P>

<A NAME="postrcsissues"></A><B>RCS vs CVS project management issues</B>

<P>
As the project owner, you are likely to deal with developers who are grappling with the differences between RCS and CVS. Here are some key differences to clarify:
<P>
<UL>
<LI>One of the central principals in RCS is file locking, which prevents other developers from checking out or modifying a file when someone else has checked it out. The benefit of file locking is that developers never have to deal with conflicting modifications within files. RCS controls versioning by only allowing files to be modified by one person at a time. Therefore, the drawback to RCS is: no one can commit changes to files while another developer has them checked out.
<P>
<LI>The central tenant of CVS is ability for developers to concurrently  check out, modify, and commit files, which greatly benefits projects with developers participating remotely. The tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is by manually editing affected files.
</UL>
<P>
(The above information is also included in CVS documentation for developers on this site)
<P>
<A NAME="cvspermissions"></A><B>Managing CVS permissions</B>
<P>

CVS read-access is determined by whether your project is licensed open source or proprietary. Open source projects allow source file read access for any site user by default, whether or not they are project members.
<P>
You determine the CVS write-access permissions held by participants in both open source and proprietary projects through the roles you grant to them as the Project Owner.<!-- or by creating groups of users within your project? or can only domain admins do that? -->.

<P>
Who gets CVS read/write permission based upon roles? Observers, that is, people you have approved for project membership but who are not actually contributing to the project, only have read-access but <I>not</I> write-access. They can check out, view, compare revisions, and update source files, but they cannot contribute modified files or new files to the source repository.
<P>
All other project membership roles automatically confer <I>both</I> cvs read/write-access to project members. This includes the ability to:
<UL>
<LI>commit changes/patches
<LI>add new files
<LI>import files
<LI>remove files
<LI>check file status
<LI>tag and branch files
</UL>
<P>
<!-- Should anything be said here about project management and earning the right by merit to do commits and higher level things in open source projects?
-->
<P>
Permissions associated with individual files cannot be altered once the file is checked into the CVS repository.
<!-- what else should be covered? What kinds of permissions are associated with individual files?
-jrobbins wrote:
"The permissions on a file when it is checked in initially will be its
permissions from then on.  (actually, that can be an annoyance if you
do it wrong at first)."

-Where does the peer review and committer status hierarchy for open source projects fit into this permissions discussion?
-->

<HR noShade SIZE=1>
<a href="Help.html">Back to main Help index</a></p></span>

</SPAN>
</TR>
</TABLE>
</BODY>
</HTML>
@


1.3
log
@added <title> tags to all files
@
text
@@


1.2
log
@removed window's nasty line breaks, and corrected more links in HelpBox files
PR:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d1 7
d126 2
@


1.1
log
@new and revised help documentation for v1.0
@
text
@d1 118
a118 118
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
<SPAN CLASS="HEADER">Project source administration for project owners</SPAN>
<P>
<SPAN CLASS="PlainText">
<UL>
<DL>
<DT><A HREF="#gettingstarted">Getting started</A>
<DT><A HREF="#siteadmincvs">CVS repository tasks handled by site administrators</A>
<DT><A HREF="#considerations">A few initial considerations for project owners</A>
	<DD><LI><A HREF="#definestructure">Starting from scratch</A>
	<DD><LI><A HREF="#postrcsissues">RCS vs CVS project management issues</A>
	<DD><LI><A HREF="#cvspermissions">Managing CVS permissions</A>
</DL>
</UL>
<P>
<A HREF="gettingstarted"></A><SPAN CLASS="InputHeader">Getting started</SPAN>
<P>
If you are new to CVS, this help guide provides some basic quick reference information for administrative CVS tasks relevant to projects hosted this site. This guide by no means exhaustively documents CVS or the many broader project management issues imputed by versioning control. A wealth of published documentation for CVS exists, both online and in print. The following links lead to general CVS information elsewhere on this site, and these documents include many authoritative, external CVS resources.
<P>
<UL>
<LI><A HREF="ddCVS.html">About CVS source code version control</A>
<LI><A HREF="ddCVS_cvsprimer.html">A CVS primer: basic concepts</A>
<LI><A HREF="ddCVS_UsingCVS_command-line.html">Using command-line CVS to work with project source files</A>
<LI><A HREF="cvscontributing.html">Contributing changes with command-line CVS</A>
</UL>
<P>
<A NAME="siteadmincvs"></A><span class="InputHeader">CVS repository tasks handled by site administrators</SPAN>
<P>
Much of the administrative work involved with setting up your project's source repository is handled "behind the scenes" when your project gains approval. In other words, because your project is hosted on this site, you do not have to start from scratch to configure CVS for your project. The following tasks occur automatically:
<P>
<UL>
<LI>Your project's basic repository structure is created with a top-level directory that can be expanded upon by adding subdirectories  as the project evolves.
<P>
<LI>Your project's CVS root (that is, the server where your CVS repository is located) is automatically set to this site's host servers and preconfigured. You can find this information by ... <!-- ADD INFO -->
<P>
<LI>Files in the CVS administrative module are preconfigured for projects hosted on this site. Those include the following, listed here for your information:
<P>
<UL>
<LI>Modules file
<LI>Cvswrappers file
<LI>Commit support files
<LI>Commitinfo
<LI>Verifying log messages
<LI>Editinfo
<LI>Loginfo
<LI>Rcsinfo
<LI>Ignoring files via cvsignore
<LI>Checkoutlist file
<LI>History file
<LI>Expansions in administrative files
<P>
</UL>
All CVS repository tasks such as backing up, restoring, moving, or configuring remote repository access are also handled by this site' administrators. Should your project requirements necessitate editing CVS administrative files or conducting repository-level actions, you must contact a site administrator for support.
</UL>
<P>
 
<A NAME="considerations"></A><SPAN CLASS="InputHeader">A few initial considerations for project owners</SPAN>
<P>
<A NAME="definestructure"></A><B>Starting from scratch</B>
<P>
When your project is completely new or still in infancy, plan the overall directory structure at the front end of project evolution. Although the top level CVS module structure is predetermined, decide how you generally want to organize source files so that you can communicate this to existing and potential contributors. Considering source structure early on enables you to maintain consistency as the project grows, and makes it easier for new contributors to get up to speed.
<P>
A good example of communicating overall project source structure is in the <A HREF="http://scarab.tigris.org/scarab-design.html#directory" target="_new">design document for the scarab open source project</A> which uses a graphic depiction. CVSWeb source browsing, provided with all projects hosted on this site, also allows users to explore your project's source structure.
<P>

<A NAME="postrcsissues"></A><B>RCS vs CVS project management issues</B>

<P>
As the project owner, you are likely to deal with developers who are grappling with the differences between RCS and CVS. Here are some key differences to clarify:
<P>
<UL>
<LI>One of the central principals in RCS is file locking, which prevents other developers from checking out or modifying a file when someone else has checked it out. The benefit of file locking is that developers never have to deal with conflicting modifications within files. RCS controls versioning by only allowing files to be modified by one person at a time. Therefore, the drawback to RCS is: no one can commit changes to files while another developer has them checked out.
<P>
<LI>The central tenant of CVS is ability for developers to concurrently  check out, modify, and commit files, which greatly benefits projects with developers participating remotely. The tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is by manually editing affected files.
</UL>
<P>
(The above information is also included in CVS documentation for developers on this site)
<P>
<A NAME="cvspermissions"></A><B>Managing CVS permissions</B>
<P>

CVS read-access is determined by whether your project is licensed open source or proprietary. Open source projects allow source file read access for any site user by default, whether or not they are project members.
<P>
You determine the CVS write-access permissions held by participants in both open source and proprietary projects through the roles you grant to them as the Project Owner.<!-- or by creating groups of users within your project? or can only domain admins do that? -->.

<P>
Who gets CVS read/write permission based upon roles? Observers, that is, people you have approved for project membership but who are not actually contributing to the project, only have read-access but <I>not</I> write-access. They can check out, view, compare revisions, and update source files, but they cannot contribute modified files or new files to the source repository.
<P>
All other project membership roles automatically confer <I>both</I> cvs read/write-access to project members. This includes the ability to:
<UL>
<LI>commit changes/patches
<LI>add new files
<LI>import files
<LI>remove files
<LI>check file status
<LI>tag and branch files
</UL>
<P>
<!-- Should anything be said here about project management and earning the right by merit to do commits and higher level things in open source projects?
-->
<P>
Permissions associated with individual files cannot be altered once the file is checked into the CVS repository.
<!-- what else should be covered? What kinds of permissions are associated with individual files?
-jrobbins wrote:
"The permissions on a file when it is checked in initially will be its
permissions from then on.  (actually, that can be an annoyance if you
do it wrong at first)."

-Where does the peer review and committer status hierarchy for open source projects fit into this permissions discussion?
-->

<HR noShade SIZE=1>
<a href="Help.html">Back to main Help index</a></p></span>

</SPAN>
</TR>
</TABLE>
@

