head	1.12;
access;
symbols
	TIGRIS_1_1_0RC2:1.10
	TIGRIS_1_1_0RC1:1.10
	TIGRIS_1_1:1.10.0.4
	TIGRIS_1_0_8:1.10
	TIGRIS_1_0_8RC3:1.10
	TIGRIS_1_0_8RC2:1.10
	TIGRIS_1_0_8RC1:1.10
	TIGRIS_1_0_7:1.10
	TIGRIS_1_0_7RC3:1.10
	TIGRIS_1_0_7RC2:1.10
	TIGRIS_1_0_7RC1:1.10
	TIGRIS_1_0_6:1.10
	TIGRIS_1_0_6RC5:1.10
	TIGRIS_1_0_6RC4:1.10
	TIGRIS_1_0_6RC3:1.10
	TIGRIS_1_0_6RC2:1.10
	TIGRIS_1_0_6RC1:1.10
	TIGRIS_1_0_5:1.10
	TIGRIS_1_0_5RC6:1.10
	TIGRIS_1_0_5RC5:1.10
	TIGRIS_1_0_5RC4:1.10
	TIGRIS_1_0_5RC3:1.10
	TIGRIS_1_0_5RC2:1.10
	TIGRIS_1_0_5RC1:1.10
	TIGRIS_1_0_4:1.10
	TIGRIS_1_0_3:1.10
	TIGRIS_1_0_2:1.10
	TIGRIS_1_0_1:1.10
	TIGRIS_1_0:1.10.0.6
	TIGRIS_1_0_0:1.10
	TIGRIS_1_0_0_RC1:1.10.0.2;
locks; strict;
comment	@# @;


1.12
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches;
next	1.11;

1.11
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.10;

1.10
date	2001.03.15.03.30.59;	author lori;	state Exp;
branches
	1.10.4.1;
next	1.9;

1.9
date	2001.03.12.08.32.47;	author lori;	state Exp;
branches;
next	1.8;

1.8
date	2001.03.12.08.08.29;	author lori;	state Exp;
branches;
next	1.7;

1.7
date	2001.03.07.00.43.37;	author lori;	state Exp;
branches;
next	1.6;

1.6
date	2001.02.22.01.00.55;	author lori;	state Exp;
branches;
next	1.5;

1.5
date	2001.02.15.21.44.05;	author lori;	state Exp;
branches;
next	1.4;

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

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

1.2
date	2001.02.05.16.40.42;	author lori;	state Exp;
branches;
next	1.1;

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

1.10.4.1
date	2001.08.23.19.12.36;	author tberry;	state Exp;
branches;
next	;


desc
@@


1.12
log
@html usage revision
@
text
@  <div class="docs" id="projectownersource">
   <h2>Managing project source code</h2>

   <div class="toc">
    <h3>Project help for project owner administration: Index</h3>

    <ul>
     <li>
      <a href="ProjectOwnerAdmin.html">Project owner administration</a> 

      <ul>
       <li><a href="ProjectOwnerEdit.html">Editing and maintaining the Project Home page</a></li>

       <li><a href="ProjectOwnerNews.html">Managing project site news</a></li>

       <li><a href="ProjectOwnerFiles.html">Managing project files</a></li>

       <li><a href="ProjectOwnerMembers.html">Adding project members and approving roles</a></li>

       <li><a href="ProjectOwnerMailingLists.html">Configuring and managing project mailing lists</a></li>

       <li><a href="ProjectOwnerDocuments.html">Managing project documentation</a></li>

       <li>
        <strong>You are here:</strong> Managing project source code 

        <ul>
         <li><a href="#gettingstarted">Getting started</a></li>

         <li><a href="#siteadmincvs">About CVS repository tasks</a></li>

         <li><a href="#considerations">A few initial considerations for project owners</a></li>

         <li><a href="#cvspermissions">Managing CVS permissions</a></li>
        </ul>
       </li>

       <li><a href="ProjectOwnerIssues.html">Managing project issues and generating reports</a></li>
      </ul>
     </li>
    </ul>
   </div>

   <div class="courtesylinks">
    <p><a href="/servlets/HelpTOC">Back to the main Help index</a></p>
   </div>

   <h3><a name="gettingstarted" id="gettingstarted">Getting started</a></h3>

   <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 tool documentation elsewhere on this site, and these documents include many authoritative, external CVS resources.</p>

   <h4>CVS tool documentation</h4>

   <ul>
    <li><a href="ddCVS.html">About CVS version control</a></li>

    <li><a href="ddCVS_cvsglossary.html">A version control glossary</a></li>

    <li><a href="ddUsingCVS_command-line.html">Using command line CVS</a></li>

    <li><a href="ddUsingWinCvs.html">UsingWinCvs</a></li>
   </ul>

   <h3><a id="siteadmincvs" name="siteadmincvs">About CVS repository tasks</a></h3>

   <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. If you are new to CVS, this means that you do not have to start from scratch to set up the CVS repository for your project.</p>

   <p>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. There is also a "/www" directory created for project web content.</li>

    <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. The instructions in the <b>Project Source</b> page for your project display the exact CVS root needed to log in to the project's source repository. For most projects on this site, the cvsroot will be: 

     <p><code>:pserver:username@@cvs.projectname.thisdomain:/cvs</code></p>
    </li>
   </ul>

   <p>For CVS experts, this automation means that the CVS administrative module is preconfigured for projects hosted on this site. That includes the following files, listed here for your information:</p>

   <ul>
    <li>Modules file</li>

    <li>Cvswrappers file</li>

    <li>Commit support files</li>

    <li>Commitinfo</li>

    <li>Verifying log messages</li>

    <li>Editinfo</li>

    <li>Loginfo</li>

    <li>Rcsinfo</li>

    <li>Ignoring files via cvsignore</li>

    <li>Checkoutlist file</li>

    <li>History file</li>

    <li>Expansions in administrative files</li>
   </ul>

   <p>All CVS repository tasks such as backing up, restoring, moving, or configuring remote repository access are also handled by site administrators. Should your project require editing CVS administrative files or other repository-level actions, you must contact a site administrator for support.</p>

   <h3><a id="considerations" name="considerations">A few initial considerations for project owners</a></h3>

   <h4><a id="definestructure" name="definestructure">Starting from scratch</a></h4>

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

   <p>A good example of communicating overall project source structure is in the <a href="http://scarab.tigris.org/scarab-design.html#directory">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>

   <p><a id="postrcsissues" name="postrcsissues"></a><b>Version control project management issues</b></p>

   <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 a file while another developer has it checked out.</li>

    <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. CVS merges everyone's changes in a central repository, but the tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is to edit the file, choosing which changes to keep and which to delete, before it can be committed.</li>
   </ul>

   <h3><a id="cvspermissions" name="cvspermissions">Managing CVS permissions</a></h3>

   <p>CVS read-access to your project's source code for site users 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. Proprietary project pages are not publicly viewable, so source code access is restricted to project members.</p>

   <p>In both open source and proprietary projects, however, you as the Project Owner determine which project members will gain CVS write-access permissions through the roles you grant to them.</p>

   <p>Observers, that is, users you have approved for project membership but who are not actually contributing source code to the project, have read-access but <i>not</i> write-access to your project's source repository . 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>

   <p>All other project membership roles automatically confer cvs write-access to project members. This includes the ability to:</p>

   <ul>
    <li>commit changes/patches</li>

    <li>add new files</li>

    <li>import files</li>

    <li>remove files</li>

    <li>check file status</li>

    <li>tag and branch files</li>
   </ul>

   <p>Read-write permissions associated with individual files are administered separately from CVS. Note that these permissions cannot be altered for a file once it is checked into the project's CVS repository.</p>

   <div class="courtesylinks">
    <p><a href="ProjectOwnerAdmin.html">Back to Project Owner Administration help</a><br />
    <a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>
  </div>
 


@


1.11
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d1 2
a2 10
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Managing Project Source Code</title>
<style type="text/css">
 p.c2 {font-weight: bold}
 div.c1 {margin-left: 2em}
</style>
 </head>
d4 2
a5 3
 <body>
  <div class="docs" id="docid">
<h2>Managing project source code</h2> 
d7 3
a9 1
  <p><b>Project help for project owner administration: Index</b></p>
d11 2
a12 1
  
d14 1
a14 3
  <div>
   <dl>
    <dt><a href="ProjectOwnerAdmin.html">Project owner administration</a></dt>
d16 1
a16 1
    <dd><a href="ProjectOwnerEdit.html">Editing and maintaining the Project Home page</a></dd>
d18 1
a18 1
    <dd><a href="ProjectOwnerNews.html">Managing project site news</a></dd>
d20 1
a20 1
    <dd><a href="ProjectOwnerFiles.html">Managing project files</a></dd>
d22 1
a22 1
    <dd><a href="ProjectOwnerMembers.html">Adding project members and approving roles</a></dd>
d24 2
a25 1
    <dd><a href="ProjectOwnerMailingLists.html">Configuring and managing project mailing lists</a></dd>
d27 2
a28 1
    <dd><a href="ProjectOwnerDocuments.html">Managing project documentation</a></dd>
d30 1
a30 2
    <dd>
     <b>You are here: Managing project source code</b>
d32 1
a32 2
     <ul>
      <li><b><a href="#gettingstarted">Getting started</a></b></li>
d34 3
a36 1
      <li><b><a href="#siteadmincvs">About CVS repository tasks</a></b></li>
d38 5
a42 1
      <li><b><a href="#considerations">A few initial considerations for project owners</a></b></li>
d44 3
a46 3
      <li><b><a href="#cvspermissions">Managing CVS permissions</a></b></li>
     </ul>
    </dd>
d48 1
a48 1
    <dd><a href="ProjectOwnerIssues.html">Managing project issues and generating reports</a></dd>
d50 1
a50 5
    <dt><a href="/servlets/HelpTOC">Back to the main Help index</a></dt>
   </dl>
  </div>
  
  <h3><a href="gettingstarted">Getting started</a></h3> 
d52 1
a52 1
  <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 tool documentation elsewhere on this site, and these documents include many authoritative, external CVS resources.</p>
d54 2
a55 1
  <p class="c2">CVS tool documentation</p>
d57 1
a57 2
  <dl>
   <dt><a href="ddCVS.html">About CVS version control</a></dt>
d59 1
a59 1
   <dt><a href="ddCVS_cvsglossary.html">A version control glossary</a></dt>
d61 2
a62 1
   <dt><a href="ddUsingCVS_command-line.html">Using command line CVS</a></dt>
d64 1
a64 4
   <dt><a href="ddUsingWinCvs.html">UsingWinCvs</a></dt>
  </dl>
  
  <h3><a id="siteadmincvs" name="siteadmincvs">About CVS repository tasks</a></h3> 
d66 1
a66 1
  <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. If you are new to CVS, this means that you do not have to start from scratch to set up the CVS repository for your project.</p>
d68 1
a68 1
  <p>The following tasks occur automatically:</p>
d70 2
a71 2
  <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. There is also a "/www" directory created for project web content.</li>
d73 2
a74 2
   <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. The instructions in the <b>Project Source</b> page for your project display the exact CVS root needed to log in to the project's source repository. For most projects on this site, the cvsroot will be: 
d76 3
a78 3
    <p><b>:pserver:username@@cvs.projectname.thisdomain:/cvs</b></p>
   </li>
  </ul>
d80 1
a80 1
  <p>For CVS experts, this automation means that the CVS administrative module is preconfigured for projects hosted on this site. That includes the following files, listed here for your information:</p>
d82 2
a83 2
  <ul>
   <li>Modules file</li>
d85 1
a85 1
   <li>Cvswrappers file</li>
d87 1
a87 1
   <li>Commit support files</li>
d89 1
a89 1
   <li>Commitinfo</li>
d91 1
a91 1
   <li>Verifying log messages</li>
d93 1
a93 1
   <li>Editinfo</li>
d95 1
a95 1
   <li>Loginfo</li>
d97 1
a97 1
   <li>Rcsinfo</li>
d99 1
a99 1
   <li>Ignoring files via cvsignore</li>
d101 1
a101 1
   <li>Checkoutlist file</li>
d103 1
a103 1
   <li>History file</li>
d105 2
a106 2
   <li>Expansions in administrative files</li>
  </ul>
d108 1
a108 3
  <p>All CVS repository tasks such as backing up, restoring, moving, or configuring remote repository access are also handled by site administrators. Should your project require editing CVS administrative files or other repository-level actions, you must contact a site administrator for support. </p>
  
  <h3><a id="considerations" name="considerations">A few initial considerations for project owners</a></h3> 
d110 1
a110 1
  <h4><a id="definestructure" name="definestructure">Starting from scratch</a></h4>
d112 1
a112 1
  <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>
d114 1
a114 1
  <p>A good example of communicating overall project source structure is in the <a href="http://scarab.tigris.org/scarab-design.html#directory">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>
d116 1
a116 1
  <p><a id="postrcsissues" name="postrcsissues"></a><b>Version control project management issues</b></p>
d118 1
a118 1
  <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>
d120 1
a120 2
  <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 a file while another developer has it checked out.</li>
d122 2
a123 4
   <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. CVS merges everyone's changes in a central repository, but the tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is to edit the file, choosing which changes to keep and which to delete, before it can be committed.</li>
  </ul>
  
  <h3><a id="cvspermissions" name="cvspermissions">Managing CVS permissions</a></h3> 
d125 2
a126 1
  <p>CVS read-access to your project's source code for site users 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. Proprietary project pages are not publicly viewable, so source code access is restricted to project members.</p>
d128 1
a128 1
  <p>In both open source and proprietary projects, however, you as the Project Owner determine which project members will gain CVS write-access permissions through the roles you grant to them.</p>
d130 1
a130 1
  <p>Observers, that is, users you have approved for project membership but who are not actually contributing source code to the project, have read-access but <i>not</i> write-access to your project's source repository . 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>
d132 1
a132 1
  <p>All other project membership roles automatically confer cvs write-access to project members. This includes the ability to:</p>
d134 1
a134 2
  <ul>
   <li>commit changes/patches</li>
d136 1
a136 1
   <li>add new files</li>
d138 2
a139 1
   <li>import files</li>
d141 1
a141 1
   <li>remove files</li>
d143 1
a143 1
   <li>check file status</li>
d145 1
a145 2
   <li>tag and branch files</li>
  </ul>
d147 1
a147 1
  
d149 2
a150 1
  <p>Read-write permissions associated with individual files are administered separately from CVS. Note that these permissions cannot be altered for a file once it is checked into the project's CVS repository.</p>
d152 1
a152 4
  
  
 <div class="courtesylinks"> <a href="ProjectOwnerAdmin.html">Back to Project Owner Administration help</a><br />
<a href="/servlets/HelpTOC">Back to main Help index</a></div>
d154 6
a159 4
   
 </div>
</body>
</html>
@


1.10
log
@added cvsroot info, other minor edits
@
text
@d1 2
d4 7
a10 1
<head>
d12 3
a14 1
<title>Managing Project Source Code</title>
d16 1
a16 127
</head>
<body>
<span class="HEADER">Managing project source code</span>
<p>
<span class="PlainText"><b>Project help for project owner administration: Index</b>
<p>

<ul>
<dl>
<dt><a href="ProjectOwnerAdmin.html">Project owner administration</a>
	<dd><a href="ProjectOwnerEdit.html">Editing and maintaining the Project Home page</a>
	<dd><a href="ProjectOwnerNews.html">Managing project site news</a>
	<dd><a href="ProjectOwnerFiles.html">Managing project files</a>
	<dd><a href="ProjectOwnerMembers.html">Adding project members and approving roles</a>
	<dd><a href="ProjectOwnerMailingLists.html">Configuring and managing project mailing lists</a>
	<dd><a href="ProjectOwnerDocuments.html">Managing project documentation</a>
	<dd><b>You are here: Managing project source code
		<ul>
		<li><a href="#gettingstarted">Getting started</a>
		<li><a href="#siteadmincvs">About CVS repository tasks</a>
		<li><a href="#considerations">A few initial considerations for project owners</a>
		<li><a href="#cvspermissions">Managing CVS permissions</a>
		</ul></b>
	<dd><a href="ProjectOwnerIssues.html">Managing project issues and generating reports</a>
<dt><a href="/servlets/HelpTOC">Back to the main Help index</a>
</dl>
</ul>

<p>
<hr noshade size=1>
<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 tool documentation elsewhere on this site, and these documents include many authoritative, external CVS resources.
<p>
<b>CVS tool documentation</b>
<dl>
<dt><a href="ddCVS.html">About CVS version control</a>
<dt><a href="ddCVS_cvsglossary.html">A version control glossary</a>
<dt><a href="ddUsingCVS_command-line.html">Using command line CVS</a>
<dt><a href="ddUsingWinCvs.html">UsingWinCvs</a>
</dl>
<p>
<hr noshade size=1>
<a name="siteadmincvs"></a><span class="InputHeader">About CVS repository tasks</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. If you are new to CVS, this means that you do not have to start from scratch to set up the CVS repository for your project. 
<p>
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. There is also a "/www" directory created for project web content.
<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. The instructions in the <b>Project Source</b> page for your project display the exact CVS root needed to log in to the project's source repository. For most projects on this site, the cvsroot will be:
<p> 
<b>:pserver:username@@cvs.projectname.thisdomain:/cvs</b>
</ul>
<p>
For CVS experts, this automation means that the CVS administrative module is preconfigured for projects hosted on this site. That includes the following files, 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 site administrators. Should your project require  editing CVS administrative files or other repository-level actions, you must contact a site administrator for support.
</ul>
<p>
<hr noshade size=1> 
<a name="considerations"></a><span class="InputHeader">A few initial considerations for project owners</span>
<p>
<span class="PlainText">
<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>Version control 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 a file while another developer has it 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. CVS merges everyone's changes in a central repository, but the tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is to edit the file, choosing which changes to keep and which to delete, before it can be committed.
</ul>
<p>
<hr noshade size=1>
<a name="cvspermissions"></a><span class="INPUTHEADER">Managing CVS permissions</span>
<p>
CVS read-access to your project's source code for site users 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. Proprietary project pages are not publicly viewable, so source code access is restricted to project members.
<p>
In both open source and proprietary projects, however, you as the Project Owner determine which project members will gain CVS write-access permissions through the roles you grant to them.

<p>
Observers, that is, users you have approved for project membership but who are not actually contributing source code to the project, have read-access but <i>not</i> write-access to your project's source repository . 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 cvs 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>

<p>
Read-write permissions associated with individual files are administered separately from CVS. Note that these permissions cannot be altered for a file once it is checked into the project's CVS repository.
<p>

<hr noshade size=1>
<a href="ProjectOwnerAdmin.html">Back to Project Owner Administration help</a><br>
<a href="/servlets/HelpTOC">Back to main Help index</a></p>
d18 153
a170 1
</span>
d173 2
@


1.10.4.1
log
@fixed broken link
Issue number:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d36 1
a36 1
<a name="gettingstarted"></a><span class="InputHeader">Getting started</span>
@


1.9
log
@fixed index; added link for ProjectOwnerDocuments.html
@
text
@d1 2
a2 2
<HTML>
<HEAD>
d4 1
a4 1
<TITLE>Managing Project Source Code</TITLE>
d6 15
a20 15
</HEAD>
<BODY>
<SPAN CLASS="HEADER">Managing project source code</SPAN>
<P>
<SPAN CLASS="PlainText"><B>Project help for project owner administration: Index</B>
<P>

<UL>
<DL>
<DT><A HREF="ProjectOwnerAdmin.html">Project owner administration</A>
	<DD><A HREF="ProjectOwnerEdit.html">Editing and maintaining the Project Home page</A>
	<DD><A HREF="ProjectOwnerNews.html">Managing project site news</A>
	<DD><A HREF="ProjectOwnerFiles.html">Managing project files</A>
	<DD><A HREF="ProjectOwnerMembers.html">Adding project members and approving roles</A>
	<DD><A HREF="ProjectOwnerMailingLists.html">Configuring and managing project mailing lists</A>
d22 16
a37 16
	<DD><B>You are here: Managing project source code
		<UL>
		<LI><A HREF="#gettingstarted">Getting started</A>
		<LI><A HREF="#siteadmincvs">CVS repository tasks handled by site administrators</A>
		<LI><A HREF="#considerations">A few initial considerations for project owners</A>
		<LI><A HREF="#cvspermissions">Managing CVS permissions</A>
		</UL></B>
	<DD><A HREF="ProjectOwnerIssues.html">Managing project issues and generating reports</A>
<DT><A HREF="/servlets/HelpTOC">Back to the main Help index</A>
</DL>
</UL>

<P>
<HR noShade SIZE=1>
<A HREF="gettingstarted"></A><SPAN CLASS="InputHeader">Getting started</SPAN>
<P>
d39 14
a52 14
<P>
<B>CVS tool documentation</B>
<DL>
<DT><A HREF="ddCVS.html">About CVS version control</A>
<DT><A HREF="ddCVS_cvsglossary.html">A version control glossary</A>
<DT><A HREF="ddUsingCVS_command-line.html">Using command line CVS</A>
<DT><A HREF="ddUsingWinCvs.html">UsingWinCvs</A>
</DL>
<P>
<HR noShade SIZE=1>
<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 setting up CVS for your project. 
<P>
d54 35
a88 33
<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 out what the exact CVS root for your project is by ... <!-- ADD INFO -->
</UL>
<P>
If you're experienced in CVS, the CVS administrative module is preconfigured for projects hosted on this site. These include the following files, 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's 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>
<HR noShade SIZE=1> 
<A NAME="considerations"></A><SPAN CLASS="InputHeader">A few initial considerations for project owners</SPAN>
<P>
<SPAN CLASS="PlainText">
<A NAME="definestructure"></A><B>Starting from scratch</B>
<P>
d90 3
a92 3
<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>
d94 1
a94 1
<A NAME="postrcsissues"></A><B>Version control project management issues</B>
d96 1
a96 1
<P>
d98 31
a128 36
<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 a file while another developer has it 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. CVS merges everyone's changes in a central repository, but the tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is to edit the file, choosing which changes to keep and which to delete, before it can be committed.
</UL>
<P>
<HR noShade SIZE=1>
<A NAME="cvspermissions"></A><SPAN CLASS="INPUTHEADER">Managing CVS permissions</SPAN>
<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>
In both open source and proprietary projects, you determine the CVS write-access permissions held by project members 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>
Observers, that is, users you have approved for project membership but who are not actually contributing source code to the project, have read-access but <I>not</I> write-access to your project's source repository . 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)."
d130 2
a131 5
-Where does the peer review and committer status hierarchy for open source projects fit into this permissions discussion?
-->

<HR noShade SIZE=1>
<A HREF="ProjectOwnerAdmin.html">Back to Project Owner Administration help</A><BR>
d134 3
a136 3
</SPAN>
</BODY>
</HTML>
@


1.8
log
@fixed broken link
@
text
@a7 2
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
d21 1
a140 2
</TR>
</TABLE>
@


1.7
log
@updated page index; misc revisions
@
text
@d45 1
a45 1
<DT><A HREF="ddUsingCVS.html">Using command line CVS</A>
@


1.6
log
@revising document index and links
@
text
@d109 1
a109 1
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? -->.
d112 1
a112 1
Who gets CVS read/write permission based upon the roles on this site? 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.
@


1.5
log
@html edits; revised doc index
@
text
@d23 1
a23 1
	<DD><B>You are here: Managing project source code</B>
d29 1
a29 1
		</UL>
d39 1
a39 1
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.
d41 7
a47 5
<UL>
<LI><A HREF="ddCVS.html">About CVS version control</A>
<LI><A HREF="ddCVS_cvsprimer.html">A version control glossary</A>
<LI><A HREF="ddUsingCVS.html">Guide to using command line CVS on this site
</UL>
d59 1
a59 1
<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 out what your CVS root is by ... <!-- ADD INFO -->
d79 1
a79 1
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.
d85 1
@


1.4
log
@added <title> tags to all files
@
text
@d12 1
a12 1
<SPAN CLASS="PlainText">Project help for project owner administration: Index
@


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


1.2
log
@updated for new help format
@
text
@d1 133
a133 133
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
<SPAN CLASS="HEADER">Managing project source code</SPAN>
<P>
<SPAN CLASS="PlainText">Project help for project owner administration: Index
<P>

<UL>
<DL>
<DT><A HREF="ProjectOwnerAdmin.html">Project owner administration</A>
	<DD><A HREF="ProjectOwnerEdit.html">Editing and maintaining the Project Home page</A>
	<DD><A HREF="ProjectOwnerNews.html">Managing project site news</A>
	<DD><A HREF="ProjectOwnerFiles.html">Managing project files</A>
	<DD><A HREF="ProjectOwnerMembers.html">Adding project members and approving roles</A>
	<DD><A HREF="ProjectOwnerMailingLists.html">Configuring and managing project mailing lists</A>
	<DD><B>You are here: Managing project source code</B>
		<UL>
		<LI><A HREF="#gettingstarted">Getting started</A>
		<LI><A HREF="#siteadmincvs">CVS repository tasks handled by site administrators</A>
		<LI><A HREF="#considerations">A few initial considerations for project owners</A>
		<LI><A HREF="#cvspermissions">Managing CVS permissions</A>
		</UL>
	<DD><A HREF="ProjectOwnerIssues.html">Managing project issues and generating reports</A>
<DT><A HREF="/servlets/HelpTOC">Back to the main Help index</A>
</DL>
</UL>

<P>
<HR noShade SIZE=1>
<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 version control</A>
<LI><A HREF="ddCVS_cvsprimer.html">A version control glossary</A>
<LI><A HREF="ddUsingCVS.html">Guide to using command line CVS on this site
</UL>
<P>
<HR noShade SIZE=1>
<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 setting up CVS for your project. 
<P>
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 out what your CVS root is by ... <!-- ADD INFO -->
</UL>
<P>
If you're experienced in CVS, the CVS administrative module is preconfigured for projects hosted on this site. These include the following files, 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>
<HR noShade SIZE=1> 
<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>Version control 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 a file while another developer has it 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. CVS merges everyone's changes in a central repository, but the tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is to edit the file, choosing which changes to keep and which to delete, before it can be committed.
</UL>
<P>
<HR noShade SIZE=1>
<A NAME="cvspermissions"></A><SPAN CLASS="INPUTHEADER">Managing CVS permissions</SPAN>
<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 the roles on this site? 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="ProjectOwnerAdmin.html">Back to Project Owner Administration help</A><BR>
<a href="/servlets/HelpTOC">Back to main Help index</a></p>

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


1.1
log
@new and revised help documentation for v1.0
@
text
@d3 1
a3 1
<SPAN CLASS="HEADER">Project source administration for project owners</SPAN>
d5 3
a7 1
<SPAN CLASS="PlainText">
d10 15
a24 6
<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>
<DT><A HREF="#cvspermissions">Managing CVS permissions</A>
d27 1
d35 3
a37 5
<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.html">Using command-line CVS to access project source files</A>
<LI><A HREF="ddCVS_cvscontributing.html">Contributing changes with command-line CVS</A>
<LI><A HREF="ddCVS_cvsmanaging.html">File management with command-line CVS</A>
d43 3
a45 1
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:
d50 2
a51 1
<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 -->
d53 1
a53 1
<LI>Files in the CVS administrative module are preconfigured for projects hosted on this site. Those include the following, listed here for your information:
d83 1
a83 1
<A NAME="postrcsissues"></A><B>RCS vs CVS project management issues</B>
d89 1
a89 1
<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.
d91 1
a91 1
<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.
a93 2
(The above information is also included in CVS documentation for developers on this site)
<P>
d95 1
a95 1
<A NAME="cvspermissions"></A><B>Managing CVS permissions</B>
a96 1

d102 1
a102 1
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.
d128 2
a129 1
<a href="Help.html">Back to main Help index</a></p></span>
@

