Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/cvsmanaging.html ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/cvsmanaging.html (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/cvsmanaging.html Sat Apr 8 23:00:09 2017 @@ -0,0 +1,164 @@ +<!--#include virtual="/doctype.html" --> +<html> +<head> +<link href="/css/ooo.css" rel="stylesheet" type="text/css"> + + +<TITLE>File Management with Command-Line CVS</TITLE> + + +<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"> + +<!--#include virtual="/google-analytics.js" --> +<!--#include virtual="/scripts/entourage.js" --> +</head> +<body> +<!--#include virtual="/pl/brand.html" --> + <div id="topbara"> + <!--#include virtual="/pl/topnav.html" --> + <div id="breadcrumbsa"><a href="/">home</a> » <a href="/pl/">pl</a> » <a href="/pl/Archive/">Archive</a> » <a href="/pl/Archive/trans/">trans</a> » <a href="/pl/Archive/trans/docs/">docs</a> » <a href="/pl/Archive/trans/docs/orig/">orig</a></div> + </div> + <div id="clear"></div> + + + <div id="content"> + + + +<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%"> + <TR> + <TD CLASS="Header" NOWRAP>File management with command-line CVS</TD> + </TR> +</TABLE> + +<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" WIDTH="100%"> + <TR> +<SPAN CLASS="PlainText"> +<UL> +<DL> +<DT><A HREF="#managing">Managing project files and directories</A> + <DD><A HREF="#cvsrelease">Releasing</A> + <DD><A HREF="#cvsremove">Removing</A> + <DD><A HREF="#cvsrename&move">Renaming and moving</A> +<DT><A HREF="#aboutbranching">Tagging and branching</A> + <DD><A HREF="#cvstag">Creating tags</A> + <DD><A HREF="#cvsbranch">Creating branches</A> +</DL> +</UL> +<P> +<A NAME="managing"><span class="InputHeader">Managing project files</SPAN></A> +<P> +At certain point in a project's development cycle, managing your project's source repository invariably involves dealing with files and directories that have become deprecated or obsolete. The decision is made to abandon a certain piece of functionality within a module, for example. Or perhaps an change in infrastructure demands getting rid of some files and moving others. This section deals with several methods for dealing with such file management issues in CVS. +<P> +<A NAME="cvsrelease"></A><SPAN CLASS="InputHeader">Releasing files and directories</SPAN> +<P> +<I>Releasing</I> refers to a way of designating certain directories or modules that will no longer to be used in the project. The command to release is invoked within a working copy and effectively cancels cvs checkouts for the designated directories and their files. Unless these are expressly deleted, the files and directories actually remain intact within the repository, including all file revision history, but are no longer included in when working copies are checked out. +<P> +The command to release a file or directory is: +<BLOCKQUOTE> +<B>cvs rel filename</B> (or <B>/directory_name</B>) +</BLOCKQUOTE> +<P> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC122"; TARGET="_new">More about releasing</A> +<P> +<A NAME="cvsremove"></A><P><I>Removing</I> is another way to get rid of files when you no longer want or need them to be part of the project's source repository. To do this, you must first delete the file from the working copy you have checked out on your local system. +<P> +Then, to remove a file from the shared repository, type: <BR> +<BLOCKQUOTE> + <B>cvs remove filename</B> +</BLOCKQUOTE> +After you have removed one or more files, you must commit your changes. +<P> +With "<B>cvs remove</B>" (or "<B>cvs rm</B>"), the old file is not completely eradicated but rather stored in CVS' so-called "attic" along with its complete revision history. +<P> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_12.html#SEC62"; TARGET="_new">More about removing files</A><BR> +<A HREF="http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File"; TARGET="_new">What happens when you remove a file</A> + +<P> +<A NAME="cvsrename&move"></A><SPAN CLASS="InputHeader">Renaming and moving files and directories</SPAN> + +<P>If you have imported some existing source code into your repository, you may have files and directories you want to rename or or move. + +<P>The best way to rename a file in your working copy involves a series of steps. Use: +<BLOCKQUOTE> +<B>cvs rm old_filename</B> +</BLOCKQUOTE> +to remove the old name, then +<BLOCKQUOTE> +<B>cvs add new_filename</B> +</BLOCKQUOTE> +and finally, +<BLOCKQUOTE> +<B>cvs commit new_filename</B> +</BLOCKQUOTE> + +<P> +There really is no specific way in CVS to remove or rename directories. However, you can produce that effect by creating a new directory, moving the files you need into it, removing unwanted files from the old directory, and then simply no longer using it. Later, you can "prune" these empty directories the next time you a check out a working copy by using: +<BLOCKQUOTE> +<B>cvs checkout -P</B> +</BLOCKQUOTE> +Another way to prune directories with no more files is to update with: +<BLOCKQUOTE> +<B>cvs update -dP</B> +</BLOCKQUOTE> + +<P> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_14.html#SEC67"; TARGET="_new">More about moving and renaming files</A><BR> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_15.html#SEC71"; TARGET="_new">More about moving and renaming directories</A> + + +<P> +<A NAME="aboutbranching"></A><SPAN CLASS="InputHeader">Tagging and branching </SPAN> +<P> +The CVS repository for your project hosted on this site supports branching and tagging your source files. At certain points in your project, you may want to enable development work in your project to progress in more than one direction simultaneously. Instead of maintaining a singular, linear path of development, CVS branching provides a way to divert or split the source tree for ancillary development activities without impacting progress of the project's primary effort. Examples of reasons to branch include: +<UL> +<LI>to distinguish a clearly defined set of functionality in project source files for QA and testing, or +<LI>when you want to try an experiment such as added features or functionality without affecting the project's progress. +</UL> +<P> +Tagging is included in the discussion about branching because the two operations are used in conjunction. Tagging allows you to "take a snapshot" of the overall project's state at a certain point in time, for example, to preserve a build with some particular characteristic. Because CVS manages individual file revisions, tagging is an important option for benchmarking the overall state of project source code. Files included in a tag will most likely be at different points in their respective revision numbering. +<P> +The critical difference between branching and tagging is the reason they are complimentary operations: +<BLOCKQUOTE> + Branching affects <I>individual files'</I> revision numbering, whereas tagging assigns a common identifying marker <I>across all project files</I> at a fixed point in time. +</BLOCKQUOTE> +So, for example, project files are often tagged at the point where branches are created. +<P> +Ultimately, branches in your project with successful outcomes get incorporated or merged back in to the main development trunk. When that happens -- and it may occur repeatedly on large or long-term projects -- identifying the point where this merge occurs is another reason to create a tag. +<P> +<A NAME="cvstag"></A>To tag project files, type: +<blockquote> +<B>cvs tag unique_tag_name</B> +</BLOCKQUOTE> +<P> +Your tag name can be a release name or date, a product version identifier, or whatever you choose. +<P> +<A NAME="cvsbranch"></A>To create a branch, type: +<blockquote> +<B>cvs tag -b unique_tag_name </B> +</BLOCKQUOTE> +<P> +Branching and tagging are complex topics with many considerations and options. You can find more comprehensive information and instructions in the following resources: +<P> +<UL> +<DL> +<DT><LI>cvshome.org: <A HREF="http://www.cvshome.org/docs/manual/cvs_4.html#SEC48"; TARGET="_new">"More about branching and tagging"</A><BR> +<DT><LI>The Cederqvist Manual: <A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_8.html#SEC50"; TARGET="_new">"Branches"</A><BR> +<DT><LI><I>Open Source Development with CVS</I>:<BR> +<DD><A HREF="http://cvsbook.red-bean.com/cvsbook.html#Marking_A_Moment_In_Time__Tags_"; target="_new">"Marking A Moment In Time (Tags)"</A> +<DD><A HREF="http://cvsbook.red-bean.com/cvsbook.html#Branches"; TARGET="_new">"Branches"</A> +</UL> +</DL> + + +<HR noShade SIZE=1> +<a href="Help.html">Back to main Help index</a></p></span> + + +</SPAN> +</TR> +</TABLE> + </div> +<!--#include virtual="/footer.html" --> +</body> +</html>
Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS.html ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS.html (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS.html Sat Apr 8 23:00:09 2017 @@ -0,0 +1,154 @@ +<!--#include virtual="/doctype.html" --> +<html> +<head> +<link href="/css/ooo.css" rel="stylesheet" type="text/css"> + +<title>About CVS</title> + +<!--#include virtual="/google-analytics.js" --> +<!--#include virtual="/scripts/entourage.js" --> +</head> +<body> +<!--#include virtual="/pl/brand.html" --> + <div id="topbara"> + <!--#include virtual="/pl/topnav.html" --> + <div id="breadcrumbsa"><a href="/">home</a> » <a href="/pl/">pl</a> » <a href="/pl/Archive/">Archive</a> » <a href="/pl/Archive/trans/">trans</a> » <a href="/pl/Archive/trans/docs/">docs</a> » <a href="/pl/Archive/trans/docs/orig/">orig</a></div> + </div> + <div id="clear"></div> + + + <div id="content"> + + + +<span class="Header" nowrap>About source code version control with CVS</span> + + <p></p> + +<span class="PlainText"><b>CVS tool documents: Index</b> +<p></p> +<ul> +<dl> +<dt><b>You are here: About source code version control with CVS + <ul> + <li><a href="#aboutcvs">About CVS</a> + <li><a href="#commitaccess">Getting CVS commit access on open source projects</a> + <li><a href="#morecvsdoc">Further CVS documentation</a> + <li><a href="#cvsclients">CVS clients</a> + </ul></b> +<p></p> +<dt><b>More help for CVS</b> +<dd><a href="ddCVS_cvsglossary.html">A version control glossary</a> +<dd><a href="ddUsingCVS_command-line.html">Using command-line CVS to access project source files</a> +<dd><a href="ddCVS_cvscontributing.html">Contributing source code changes with CVS</a> +<dd><a href="ddCVS_cvsmanaging.html">Managing project files and directories with CVS</a> +<dt><a href="/servlets/HelpTOC">Back to main Help index</a> +</dl> +</ul> +<p> + +<hr noshade size=1> +<a name="aboutcvs"></a><span class="InputHeader">About CVS</span> + + <p>The Concurrent Versions System (CVS) is a version control system for keeping track of all modifications to project source code files. CVS is widely used in both open source and proprietary software development projects, and is generally considered to be the best freely available, full-featured version control tool. Two special features make CVS particularly suited to collaborative development across the Internet:</p> + +<ol> +<li>CVS allows multiple developers to edit their own working copies of files simultaneously, then deals with combining all the changes and notifying developers when there are conflicts.</li> +<p></p> +<li>Remote access to source code file repositories. Developers who are project members can obtain and modify project files from virtually anywhere.</li> +</ol> + + <p>CVS is a client-server system. The CVS repository is maintained on a web server; clients run on users' machines and connect to the server via the Internet. You must have a CVS client on your local machine to access the CVS server for projects hosted on this site. <a href="#cvsclients">Clients</a> are available for nearly all platforms including: Unix, Windows, Macintosh, and any Java-based platform. This documentation includes instructions for running CVS in a Unix shell or WinCVS.</p> + +<p> +As a project member, CVS allows you to:</p> + <ul> + <li>Check out source files and directories</li> + <li>View differences between versions of files</li> + <li>View change log history and comments</li> + <li>Commit changes made in your local copy of the source files to the main source code repository</li> + <li>Update your local project files when you want to remain in sync with changes committed by other project members</li> + </ul> +<p> +If you are new to CVS, one the best ways to learn about it is simply to jump in and begin using it. When you click on the <i>Source Code</i> link in the Project Resources tool bar, you can follow the instructions in that page for checking out your own working copy of a particular project's source files. +You can also find further, more specific information in this site's three-part CVS tool document, <a href="ddUsingCVS_command-line.html">Using command-line CVS</a> or <a href="ddUsingWinCvs.html">Using WinCVS</a>.</p> +<p> +For those looking for a step-by-step orientation of CVS, <a href="http://cvsbook.red-bean.com/cvsbook.html#A_Day_With_CVS"; target="_new">A Day with CVS</a>, excerpted from the online version of Karl Fogel's book, <b><i>Open Source Development with CVS</i></b>, is highly recommended. Much of the CVS help information on this site comes from this authoritative source. +</p> + +<hr noshade size=1> +<a name="commitaccess"></a><span class="InputHeader">Getting CVS commit access on open source projects</span> + <p> +Suppose you are interested in joining an open source project but you are unknown to the project owner and other project members. The logical first step is requesting to join the project, of course, but you can take some basic preliminary steps toward establishing yourself as a potential contributor, thereby raising the likelihood of gaining membership approval.</p> + <ol> + <li>Subscribe to <b>and regularly read</b> the relevant mailing lists so that you know what is going on in the particular area of development you are interested in.</li> + <p> + <li>When you post your first message to a discussion mailing list, introduce yourself and include the following:</li> + <p> + <ul> + <li>who you are</li> + <li>a few words on your background</li> + <li>your interest in the project, and</li> + <li>what you would like to see happen with the project.</li> + </ul> + <p></p> + <li>Make sure you have browsed through the existing source code and understand what it is doing and how. If something is poorly documented, confusing, or you just can't grasp what is going on, ask on the associated mailing list for a summary.</li> + <p></p> + <li>Mention in writing that you understand the licensing governing the code that you will be working on, and your agreement that any changes you contribute are your own and these can be incorporated under that license.</li> + <p></p> + <li>Request project membership to gain cvs check-in permissions on an area of the code base, and explain what sorts of things you are interested in doing with it. You will need to communicate frequently with the people who already maintain that area of code, so make sure there is consensus about what you should be working on.</li> + <p></p> + <li>When the project owner approves your project membership, you will get a CVS check-in account, probably restricted to a certain area. Make sure you understand which CVS branch you are supposed to be working on!</li> + <p></p> + <li>Submit some patches to establish that you know what you are doing.</li> + <p></p> + <li>When you make modifications and enhancements, seek feedback and discussion about these on the associated mailing lists.</li> + </ol> +<p></p> + +<hr noshade size=1> +<a name="morecvsdoc"></a><span class="InputHeader">Further CVS documentation</span> +<p></p> + <ul> + <li><a href="http://www.gnu.org/manual/cvs/index.html"; target=_new>CVS Manual</a></li> + + <li><a href="http://www.cyclic.com/"; target=_new>CVS Home Page at Cyclic</a></li> + + <li><a href="http://www.loria.fr/~molli/cvs-index.html"; target=_new>Pascal Molli's CVS page</a></li> + + <li><a href="http://dmoz.org/Computers/Software/Configuration_Management/Tools/CVS/"; target=_new>CVS Page on Dmoz</a></li> + </ul> + +<span class="InputHeader">CVS Books</span> + <ul> + <li><a href="http://www.amazon.com/exec/obidos/ISBN=0132408546/cyclicsoftwareA/"; target="_new">Practical Software Configuration Management</a> </li> + <li><a href="http://cvsbook.red-bean.com/"; target="_new">Open Source Development with CVS</a> (online chapters version)</li> + </ul> + +<p> + +<hr noshade size=1> +<a name="cvsclients"></a><span class="InputHeader">CVS Clients</span> + <ul> + <li><a + href="http://www.cyclic.com</UL></ul>m/downloads.html" target="_new">Command line clients for many systems</a></li> + + <li><a href="http://www.cvsgui.org/download.html"; target="_new">WinCVS: a Windows CVS client</a></li> + + <li><a href="http://www.jcvs.org/"; target="_new">jCVS: a Java CVS client</a></li> + + <li><a href="http://cervisia.sourceforge.net"; target="_new">Cervisia: a KDE CVS Client</a></li> + </ul> +<p> + +<hr noshade size=1> +<a href="ProjectSource.html">Back to Project Source help</a><br> +<a href="/servlets/HelpTOC">Back to main Help index</a></p></span> + + +</span> + + </div> +<!--#include virtual="/footer.html" --> +</body> +</html> Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS.html.en ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS.html.en (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS.html.en Sat Apr 8 23:00:09 2017 @@ -0,0 +1,161 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" +"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd";> + +<html xmlns="http://www.w3.org/1999/xhtml";> + <head> +<style type="text/css"> +/* <![CDATA[ */ @import "/branding/css/tigris.css"; /* ]]> */ +</style> + <script src="/branding/scripts/sc.js" type="text/javascript"></script> + <link rel="stylesheet" type="text/css" href="/branding/css/print.css" media="print" /> + + <title>About source code version control with CVS</title> + </head> + + <body class="docs" onload="self.focus()"> + <div class="docs" id="ddcvs"> + <h2>About source code version control with CVS</h2> + + <div id="toc"> + <ul> + <li><strong><a href="/nonav/servlets/HelpTOC">Help index</a></strong></li> + </ul> + + <ul> + <li><a href="/nonav/docs/Learning.html">Learning about projects</a></li> + + <li><a href="/nonav/docs/ProjectMemberResources.html">Project resources for members</a></li> + + <li> + <a href="/nonav/docs/hostedtools.html">Hosted tools</a> + + <ul> + <li> + About source code version control with CVS + + <ul> + <li><a href="#aboutcvs">About CVS</a></li> + + <li><a href="#commitaccess">Getting CVS commit access on open source projects</a></li> + + <li><a href="#morecvsdoc">Further CVS documentation</a></li> + + <li><a href="#cvsclients">CVS clients</a></li> + </ul> + </li> + + <li><a href="/nonav/docs/ProjectAdd.html">Creating a new project</a></li> + </ul> + </li> + + <li> + More help for CVS + + <ul> + <li><a href="/nonav/docs/ddCVS_cvsglossary.html">A version control glossary</a></li> + + <li><a href="/nonav/docs/ddUsingCVS_command-line.html">Using command-line CVS to access project source files</a></li> + + <li><a href="/nonav/docs/ddCVS_cvscontributing.html">Contributing source code changes with CVS</a></li> + + <li><a href="/nonav/docs/ddCVS_cvsmanaging.html">Managing project files and directories with CVS</a></li> + </ul> + </li> + </ul> + </div> + + <h3><a id="aboutcvs" name="aboutcvs">About CVS</a></h3> + + <p>The Concurrent Versions System (CVS) is a version control system for keeping track of all modifications to project source code files. CVS is widely used in both open source and proprietary software development projects, and is generally considered to be the best freely available, full-featured version control tool. Two special features make CVS particularly suited to collaborative development across the Internet:</p> + + <ol> + <li>CVS allows multiple developers to edit their own working copies of files simultaneously, then deals with combining all the changes and notifying developers when there are conflicts.</li> + + <li>Remote access to source code file repositories. Developers who are project members can obtain and modify project files from virtually anywhere.</li> + </ol> + + <p>CVS is a client-server system. The CVS repository is maintained on a web server; clients run on users' machines and connect to the server via the Internet. You must have a CVS client on your local machine to access the CVS server for projects hosted on this site. <a href="#cvsclients">Clients</a> are available for nearly all platforms including: Unix, Windows, Macintosh, and any Java-based platform. This documentation includes instructions for running CVS in a Unix shell or WinCVS.</p> + + <p>As a project member, CVS allows you to:</p> + + <ul> + <li>Check out source files and directories</li> + + <li>View differences between versions of files</li> + + <li>View change log history and comments</li> + + <li>Commit changes made in your local copy of the source files to the main source code repository</li> + + <li>Update your local project files when you want to remain in sync with changes committed by other project members</li> + </ul> + + <p>If you are new to CVS, one the best ways to learn about it is simply to jump in and begin using it. When you click on the <i>Source Code</i> link in the Project Resources tool bar, you can follow the instructions in that page for checking out your own working copy of a particular project's source files. You can also find further, more specific information in this site's three-part CVS tool document, <a href="/nonav/docs/ddUsingCVS_command-line.html">Using command-line CVS</a> or <a href="/nonav/docs/ddUsingWinCvs.html">Using WinCVS</a>.</p> + + <p>For those looking for a step-by-step orientation of CVS, <a href="http://cvsbook.red-bean.com/cvsbook.html#A_Day_With_CVS";>A Day with CVS</a>, excerpted from the online version of Karl Fogel's book, <b><i>Open Source Development with CVS</i></b>, is highly recommended. Much of the CVS help information on this site comes from this authoritative source.</p> + + <h3><a id="commitaccess" name="commitaccess">Getting CVS commit access on open source projects</a></h3> + + <p>Suppose you are interested in joining an open source project but you are unknown to the project owner and other project members. The logical first step is requesting to join the project, of course, but you can take some basic preliminary steps toward establishing yourself as a potential contributor, thereby raising the likelihood of gaining membership approval.</p> + + <ol> + <li>Subscribe to <b>and regularly read</b> the relevant mailing lists so that you know what is going on in the particular area of development you are interested in.</li> + + <li>When you post your first message to a discussion mailing list, introduce yourself and include the following:</li> + + <li> + <ul> + <li>who you are</li> + + <li>a few words on your background</li> + + <li>your interest in the project, and</li> + + <li>what you would like to see happen with the project.</li> + </ul> + </li> + + <li>Make sure you have browsed through the existing source code and understand what it is doing and how. If something is poorly documented, confusing, or you just can't grasp what is going on, ask on the associated mailing list for a summary.</li> + + <li>Mention in writing that you understand the licensing governing the code that you will be working on, and your agreement that any changes you contribute are your own and these can be incorporated under that license.</li> + + <li>Request project membership to gain cvs check-in permissions on an area of the code base, and explain what sorts of things you are interested in doing with it. You will need to communicate frequently with the people who already maintain that area of code, so make sure there is consensus about what you should be working on.</li> + + <li>When the project owner approves your project membership, you will get a CVS check-in account, probably restricted to a certain area. Make sure you understand which CVS branch you are supposed to be working on!</li> + + <li>Submit some patches to establish that you know what you are doing.</li> + + <li>When you make modifications and enhancements, seek feedback and discussion about these on the associated mailing lists.</li> + </ol> + + <h3><a id="morecvsdoc" name="morecvsdoc">Further CVS documentation</a></h3> + + <ul> + <li><a href="http://www.gnu.org/manual/cvs/index.html";>CVS Manual</a></li> + + <li><a href="http://www.cyclic.com/";>CVS Home Page at Cyclic</a></li> + + <li><a href="http://www.loria.fr/~molli/cvs-index.html";>Pascal Molli's CVS page</a></li> + + </ul> + + <h3>CVS Books</h3> + + <ul> + <li><a href="http://www.amazon.com/exec/obidos/ISBN%3D0132408546/cyclicsoftwareA/";>Practical Software Configuration Management</a></li> + + <li><a href="http://cvsbook.red-bean.com/";>Open Source Development with CVS</a> (online chapters version)</li> + </ul> + + <h3><a id="cvsclients" name="cvsclients">CVS Clients</a></h3> + + <p>You can download several CVS clients from <a href="http://www.collab.net/developers/tools/";>CollabNet Deleloper Tools page</a>.</p> + + <div class="courtesylinks"> + <p><a href="#toc">Top</a> | <a href="/nonav/servlets/HelpTOC">Help index</a></p> + </div> + </div> + </body> +</html> + + Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvscontributing.html ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvscontributing.html (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvscontributing.html Sat Apr 8 23:00:09 2017 @@ -0,0 +1,293 @@ +<!--#include virtual="/doctype.html" --> +<html> +<head> +<link href="/css/ooo.css" rel="stylesheet" type="text/css"> + +<TITLE>Contributing changes with CVS</TITLE> + +<!--#include virtual="/google-analytics.js" --> +<!--#include virtual="/scripts/entourage.js" --> +</head> +<body> +<!--#include virtual="/pl/brand.html" --> + <div id="topbara"> + <!--#include virtual="/pl/topnav.html" --> + <div id="breadcrumbsa"><a href="/">home</a> » <a href="/pl/">pl</a> » <a href="/pl/Archive/">Archive</a> » <a href="/pl/Archive/trans/">trans</a> » <a href="/pl/Archive/trans/docs/">docs</a> » <a href="/pl/Archive/trans/docs/orig/">orig</a></div> + </div> + <div id="clear"></div> + + + <div id="content"> + + + +<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%"> + <TR> + <SPAN CLASS="Header">Contributing source code changes with command-line CVS</SPAN> +<P> +<SPAN CLASS="PlainText"><B>CVS tool documents: Index</B> +<P> +<UL> +<DL> +<DT><A HREF="ddCVS.html">About source code version control with CVS</A> +<DT><A HREF="ddCVS_cvsglossary.html">A version control glossary</A> +<DD><A HREF="ddUsingCVS_command-line.html">Using command-line CVS to access project source files</A> +<DD><B>You are here: Contributing source code changes with CVS +<UL> + <LI><A HREF="#cvscommit">Committing files and directories</A> + <LI><A HREF="#cvsadd">Adding new files and directories</A> + <LI><A HREF="#work">Working with files</A> + <LI><A HREF="#filetypes">About file types</A> + <LI><A HREF="#cvsupdate">Keeping your working copy up to date (cvs update)</A> + <LI><A HREF="#cvstatus">Comparing your working files to the CVS repository</A> + <LI><A HREF="#otherdiff">Comparing files before you commit</A> + <LI><A HREF="#cvsmerging">Merging your changes</A> + <LI><A HREF="#cvsresolving">Resolving merge conflicts</A> + <LI><A HREF="#reverting">Revision history and reverting</A> +</UL></B> +<DD><A HREF="ddCVS_cvsmanaging.html">Managing project files and directories with CVS</A> +<DT><A HREF="/servlets/HelpTOC">Back to main Help index</A> +</DL> +</UL> +<P> + +<HR NOSHADE SIZE=1> +<SPAN CLASS="InputHeader"><A NAME="contributing"></A>Contributing your changes into CVS</SPAN> +<P> +<A NAME="cvscommit"></A>To <I>commit</I> your changes to a file into the shared repository, type: +<BLOCKQUOTE> + <B>cvs commit -m "Type your changes message here" filename</B> +</BLOCKQUOTE> +<P> +If you do not include a description of your change to the file, you will be prompted to add it by invoking your file editor before CVS can complete the commit action. +<P> +To commit your changes to all files in a directory and any subdirectories: +<BLOCKQUOTE> + <B>cd top_directory_to_commit</B><BR> + <B>cvs commit -m "Type your change message here"</B> +</BLOCKQUOTE> +<P> +All commits are logged automatically and posted to the project's cvs mailing list. +<P> +<HR NOSHADE SIZE=1> +<A NAME="cvsadd"></A><SPAN CLASS="InputHeader">Adding files/directories</SPAN> + + <P>To <I>add</I> a new file to the CVS repository after you have first created and edited it in your working directory, type: +<BLOCKQUOTE> + <B>cvs add filename</B><BR> +</BLOCKQUOTE> + Then follow up with the "cvs commit filename" command. If you do not first add the file, CVS does not recognize it.</LI> + +<P> +If you have cvs write permissions, you can add subdirectories to your project's source tree using the "<B>cvs add</B>" command. You can then move existing files into new subdirectories with the "<B>cvs move</B>" command. +<P> +<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Committing"; TARGET="_new">More about committing changes</A><BR> +<A HREF="http://cvshome.org/docs/manual/cvs_7.html#SEC66"; TARGET="_new">More about adding files and directories</A> +<P> + +<HR NOSHADE SIZE=1> +<SPAN CLASS="InputHeader"><A NAME="work"></A>Working with files</SPAN> +<P> +Between checking files out of the project repository and checking them back in, CVS has virtually nothing to do with how files are used in the project environment or build process. That is governed by the project owner and other external factors unique to the project. +<P> +When you make changes to existing files, you must edit your working copies of these files in a file editor on your local machine using your file editor of choice. None of the changes you make to your working files has any effect on the project's source repository or on other developers' work until you check in (that is, do a <I>cvs commit</I>) your modified versions of files. +<P> +More about "<A HREF="http://www.cvshome.org/docs/manual/cvs_1.html#SEC1"; TARGET=_NEW>What CVS is not</A>." +<P> + +<HR NOSHADE SIZE=1> +<SPAN CLASS="InputHeader"><A NAME="filetypes"></A>About file types</SPAN> +<P> +<P> +The information provided in this document about CVS commands and actions assumes that the project files you are working with are text files. It is possible to include binary files in version control with CVS, although there are some special issues. +<P> +More about <A HREF="http://cvshome.org/docs/manual/cvs_9.html#SEC80"; TARGET="_new">Handling binary files</A> in CVS. +<P> + +<HR NOSHADE SIZE=1> +<A NAME="cvsupdate"></A><SPAN CLASS="InputHeader">Keeping your working files up to date with the repository</SPAN> +<P> +If you want to look before you leap, you can get a list of all files in your local directory not up to date with the project repository by using the following command:<BR> +<BLOCKQUOTE> + <B>cvs -qn update</B> </LI> +</BLOCKQUOTE> +Files in the affected directory or directories are listed with their current status indicated as follows: +<UL> +<LI>? = File is unrecognized by CVS (needs to be added and committed). +<LI>A = File is added; file is recognized by CVS but still needs to be committed to the repository. +<LI>M = File has been modified by another developer since you checked out your working copy. This means that you need to update. +<LI>U = File is updated. +<LI>C = File has merge conflicts that must be resolved by hand. +</UL> +<P> +To go ahead and actually perform an update to make your working directory up to sync with the repository, the command is: +<BLOCKQUOTE> + <B>cvs update</B> +</BLOCKQUOTE> +You can also update individual files by adding the filename to the command. +<P>Or, to include any new directories when updating, do: +<BLOCKQUOTE> + <B>cvs update -d</B> +</BLOCKQUOTE> +<P> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC132"; TARGET="_new">More about the cvs update command</A><BR> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC134"; TARGET="_new">More about CVS update output</A> +<P> + +<HR NOSHADE SIZE=1> +<A NAME="cvstatus"></A><SPAN CLASS="InputHeader">Comparing your working files to the repository</SPAN> +<P> +Another way to determine whether all of your working files are in sync with the latest versions in the repository is with the command: +<BLOCKQUOTE> +<B>cvstatus</B><BR> +</BLOCKQUOTE> +or for status on individual files:<BR> +<BLOCKQUOTE> +<B>cvs status filename</B> +</BLOCKQUOTE> +<P> +This comparison may return one of the following messages: +<P> +<dl> + <dt><b>Locally Added</b></dt> + <dd>You have added the file with `add', and not yet committed your + changes.</dd> + + <dt><b>Locally Removed</b></dt> + <dd>You have removed the file with `remove', and not yet committed + your changes.</dd> + + <dt><b>Needs Checkout</b></dt> + <dd>Someone else has committed a newer revision to the repository. + The name is slightly misleading; you will ordinarily use `update' + rather than `checkout' to get that newer revision.</dd> + + <dt><b>Needs Patch</b></dt> + + <dd>Like Needs Checkout, but the CVS server will send a patch rather + than the entire file. Sending a patch or sending an entire file + accomplishes the same thing.</dd> + + <dt><b>Needs Merge</b></dt> + <dd>Someone else has committed a newer revision to the repository, and + you have also made modifications to the file.</dd> + + <dt><b>File had conflicts on merge</b></dt> + + <dd>This is like Locally Modified, except that a previous `update' + command gave a conflict and CVS could not resolve the changes made. If you have not already done so, you need to open the file in an editor and <a href="ddCVS_cvscontributing.html#cvsresolving">resolve the conflict</a>.</dd> + + <dt><b>Unknown</b></dt> + <dd>CVS doesn't know anything about this file. For example, you have + created a new file and have not run `cvs add'.</dd> + </dl> + + + + + + + + + + + + + + + + + + +<P> +In general, a good rule of thumb is to make sure your working files are up to date with the repository <I>just before you commit your changes to a file</I>. The reason for this is that sometimes your commit may be unsuccessful, for example, you may be trying to commit from the wrong directory or perhaps another developer has committed changes to that same file after you checked it out of the repository or last updated it. Trying to commit your changes to an older version of the same file often causes conflicts when CVS tries to merge these. The result of your commit attempt under such circumstances is a somewhat daunting failure message about "dying gasps" from CVS. (Unfortunately, you don't find this out until <I>after</I> you've gone through the process of mentally composing and entering a pithy change log message.) +<P> +To see the differences between your copy of a file and the latest version in the repository:<BR> +<BLOCKQUOTE> + <B>cvs diff filename</B> </LI> +</BLOCKQUOTE> +<P> +<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Finding_Out_What_You__And_Others__Did_--_update_And_diff"; TARGET=_NEW>More about comparing your work with the project repository</A> +<P> + +<HR NOSHADE SIZE=1> +<A NAME="diffs"></A><SPAN CLASS="InputHeader">Comparing versions of files <I>before</I> you commit (diff)</SPAN> +<P> +Perhaps you want to see the changes another developer has made to the same file <I>before</I> you commit your own changes. For example, suppose you are committing some very complex changes which you anticipate may conflict with another developer's work. +<P> +In this case, a workable solution is to save off your working file under a different name (something like: "filename-new"). Then you can run the "<B>cvs update</B>" command and compare the latest version from the repository with your file before committing your changes. You can even compare the two files side-by-side using the following diff command: +<BLOCKQUOTE> +<B>diff -y filename filename-new</B> +</BLOCKQUOTE> +<P> + +<HR NOSHADE SIZE=1> +<A NAME="cvsmerging"></A><SPAN CLASS="InputHeader">Merging your changes with other developers' changes</SPAN> +<P> +By giving the "<B>cvs update</B>" command, you are essentially telling CVS to merge the latest versions of files from the repository into your working copies. +<P> +Sometimes, however, other modifications made to a file since you last updated do not mesh well with your version. Or, you've made changes that conflict with the repository version. CVS makes every attempt to resolve such conflicts automatically when you update and commit, but sometimes it cannot resolve everything. Conflicts within the file must be resolved by hand. +<P> + +<HR NOSHADE SIZE=1> +<A NAME="cvsresolving"></A><SPAN CLASS="InputHeader">Resolving merge conflicts</SPAN> +<P> +To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by <B>>>>>>></B> and <B><<<<<<<</B>. When CVS cannot resolve a conflict, it includes both verions of the affected line or sections inthe file, with the latest version usually first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revisions numbers. Then you can save the file and commit again. + +<P> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_7.html#SEC40"; TARGET="_new">An example of a conflict</A><BR> +<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Detecting_And_Resolving_Conflicts"; TARGET="_new">More about resolving conflicts</A> +<P> + +<HR NOSHADE SIZE=1> +<A NAME="reverting"></A><SPAN CLASS="InputHeader">Revision history and reverting</SPAN> +<P> +Beyond the usefulness of being able to review a file's modification history using the "<B>cvs log</B>" command, those earlier file revisions can actually be restored as the most current revision (that is, restored to the "repository head") by the process of <I>reverting</I>. This becomes a particularly useful option if you need to return to an earlier point in a file's evolution for whatever reason, somewhat like being able to turn back the clock. When development projects experience broken builds or other problems, this becomes one of the most useful and powerful features of version control. +<P> +A word of caution: it's easy to get confused by the terminology of "revisions" versus "versions." <I>Revisions</I> are specific updates to individual files, such 1.1, 1.2, 1.3. When you run the "cvs log filename" command, the results are all of that particular file's revision numbers. By contrast, <I>versions</I> are <B><I>sets</I></B> of file revisions that are tagged and named at a certain point in time. The confusion occurs because versions are sometimes named similarly to file revisions (1.0, 1.1, 1.2 etc.). But versions do not have to be named this way; they can be any set of characters the Project Owner designates, and probably should use a different numbering scheme. + +<P> +First, before you attempting to do any reverting, it's recommended that you examine the differences between the file version currently at the head of the repository and the version you want to revert to. The command to do this is: +<BLOCKQUOTE> +<B>cvs diff -c -r version# -r version# filename</B> +</BLOCKQUOTE> +<P> +This enables you to compare the two files before attempting to revert. The order for the file versions in this command is not critical, as long as you know can distinguish between the two versions. +<P> +The command to revert requires strict observance in ordering the version numbers, however. Assuming you want to revert from a later version to an earlier version, the command is: +<BLOCKQUOTE> +<B>cvs update -j later_version# -j earlier_version# filename</B> +</BLOCKQUOTE> +<P> +Because there is more than one method for reverting, see also:<BR> +<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Examining_And_Reverting_Changes"; TARGET="_new">More about reverting</A><BR> +<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_16.html#SEC72"; TARGET="_new">More about revision history</A><BR> +<P> + +You should also know that reverting may result in "sticky tag" errors. These can be resolved using the following update command with a special switch: +<BLOCKQUOTE> +<B>cvs update -dAP</B> +</BLOCKQUOTE> +(<A H REF="http://cvsbook.red-bean.com/cvsbook.html#Getting_Snapshots__Dates_And_Tagging_"; TARGET="_new">What are sticky tag errors?</A>) +<P> + +<!-- +<P> +<A NAME="cvstips"><span class="InputHeader">Feedback on this document</span></A> +<P> +The author of this help document has made every attempt to compile accurate, helpful information about using CVS for projects hosted on this site. If you think any content in the above document is wrong, inadequate, or something is just plain missing ... that's good. This is open source, so step up to the plate and contribute your suggestions for additions and improvements. +<P> +--> + +<HR NOSHADE SIZE=1> +More CVS help: <A HREF="ddCVS_cvsmanaging.html">Managing project files and directories with command line CVS</A><BR> +<A HREF="/servlets/HelpTOC">Back to main Help index</A></P></SPAN> + +</SPAN> +</TR> +</TABLE> + + </div> +<!--#include virtual="/footer.html" --> +</body> +</html> Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvscontributing.html.en ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvscontributing.html.en (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvscontributing.html.en Sat Apr 8 23:00:09 2017 @@ -0,0 +1,284 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" +"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd";> + +<html xmlns="http://www.w3.org/1999/xhtml";> + <head> +<style type="text/css"> +/* <![CDATA[ */ @import "/branding/css/tigris.css"; /* ]]> */ +</style> + <script src="/branding/scripts/sc.js" type="text/javascript"></script> + <link rel="stylesheet" type="text/css" href="/branding/css/print.css" media="print" /> + + <title>Contributing source code changes</title> + </head> + + <body class="docs" onload="self.focus()"> + <div class="docs" id="ddcvscvscontributing"> + <h2>Contributing source code changes with command-line CVS</h2> + + <div id="toc"> + <ul> + <li><strong><a href="/nonav/servlets/HelpTOC">Help index</a></strong></li> + </ul> + + <ul> + <li> + <a href="/nonav/docs/ddCVS.html">About source code version control with CVS</a> + + <ul> + <li><a href="/nonav/docs/ddCVS_cvsglossary.html">A version control glossary</a></li> + + <li><a href="/nonav/docs/ddUsingCVS_command-line.html">Using command-line CVS to access project source files</a></li> + + <li> + Contributing source code changes with CVS + + <ul> + <li><a href="#cvscommit">Committing files and directories</a></li> + + <li><a href="#cvsadd">Adding new files and directories</a></li> + + <li><a href="#work">Working with files</a></li> + + <li><a href="#filetypes">About file types</a></li> + + <li><a href="#cvsupdate">Keeping your working copy up to date (cvs update)</a></li> + + <li><a href="#cvstatus">Comparing your working files to the CVS repository</a></li> + + <li><a href="#otherdiff">Comparing files before you commit</a></li> + + <li><a href="#cvsmerging">Merging your changes</a></li> + + <li><a href="#cvsresolving">Resolving merge conflicts</a></li> + + <li><a href="#reverting">Revision history and reverting</a></li> + </ul> + </li> + + <li><a href="/nonav/docs/ddCVS_cvsmanaging.html">Managing project files and directories with CVS</a></li> + </ul> + </li> + </ul> + </div> + + <h3><a id="contributing" name="contributing">Contributing your changes into CVS</a></h3> + + <p><a id="cvscommit" name="cvscommit"></a>To <i>commit</i> your changes to a file into the shared repository, type:</p> + + <p><code>cvs commit -m "Type your changes message here" filename</code></p> + + <p>If you do not include a description of your change to the file, you will be prompted to add it by invoking your file editor before CVS can complete the commit action.</p> + + <p>To commit your changes to all files in a directory and any subdirectories:</p> +<pre> +<code>cd top_directory_to_commit +cvs commit -m "Type your change message here" +</code> +</pre> + + <p>All commits are logged automatically and posted to the project's cvs mailing list.</p> + + <h3><a id="cvsadd" name="cvsadd">Adding files/directories</a></h3> + + <p>To <i>add</i> a new file to the CVS repository after you have first created and edited it in your working directory, type:</p> + + <p><code>cvs add filename</code></p> + + <p>Then follow up with the "cvs commit filename" command. If you do not first add the file, CVS does not recognize it.</p> + + + <p>If you have cvs write permissions, you can add subdirectories to your project's + source tree using the "<b>cvs add</b>" command. To move existing files into + a new subdirectory you must first copy or move the files to the new location, + use the "<b>cvs add</b>" command to add to the repository in the + new location and then commit the files using the "<b>cvs commit</b>" + command. To remove the files from their previous location, make sure the files + are no longer physically in that directory on your local drive, then use the + "<b>cvs remove</b>" command and commit using the "<b>cvs commit</b>" + command to remove them from the repository.</p> + + <p>NOTE: Naming directories for CVS should be done with caution. The CVS repository is accessible by users on varying operating systems, some of which cannot read certain characters in directory names. While .,~, /, \ and other characters may be legal characters for directory names in your operating system, someone else who needs to access your directory may not be able to use your file organization schema. To avoid conflict with other users, you should use only the following characters in your directory names:</p> + + <blockquote> + <p>a-z, A-Z 0-9 and _(underscore)</p> + </blockquote> + + <p>Adding other characters will render your directory names unreadable by users on other operating systems.</p> + + <ul> + <li><a href="http://cvsbook.red-bean.com/cvsbook.html#Committing";>More about committing changes</a></li> + + <li><a href="http://cvshome.org/docs/manual/cvs_7.html#SEC66";>More about adding files and directories</a></li> + </ul> + + <h3><a id="work" name="work">Working with files</a></h3> + + <p>Between checking files out of the project repository and checking them back in, CVS has virtually nothing to do with how files are used in the project environment or build process. That is governed by the project owner and other external factors unique to the project.</p> + + <p>When you make changes to existing files, you must edit your working copies of these files in a file editor on your local machine using your file editor of choice. None of the changes you make to your working files has any effect on the project's source repository or on other developers' work until you check in (that is, do a <i>cvs commit</i>) your modified versions of files.</p> + + <p>More about "<a href="http://www.cvshome.org/docs/manual/cvs_1.html#SEC1";>What CVS is not</a>."</p> + + <h3><a id="filetypes" name="filetypes">About file types</a></h3> + + <p>The information provided in this document about CVS commands and actions assumes that the project files you are working with are text files. It is possible to include binary files in version control with CVS, although there are some special issues.</p> + + <p>More about <a href="http://cvshome.org/docs/manual/cvs_9.html#SEC80";>Handling binary files</a> in CVS.</p> + + <h3><a id="cvsupdate" name="cvsupdate">Keeping your working files up to date with the repository</a></h3> + + <p>If you want to look before you leap, you can get a list of all files in your local directory not up to date with the project repository by using the following command:</p> + + <p><code>cvs -qn update</code></p> + + <p>Files in the affected directory or directories are listed with their current status indicated as follows:</p> + + <ul> + <li>? = File is unrecognized by CVS (needs to be added and committed).</li> + + <li>A = File is added; file is recognized by CVS but still needs to be committed to the repository.</li> + + <li>M = File has been modified by another developer since you checked out your working copy. This means that you need to update.</li> + + <li>U = File is updated.</li> + + <li>C = File has merge conflicts that must be resolved by hand.</li> + </ul> + + <p>To go ahead and actually perform an update to make your working directory up to sync with the repository, the command is:</p> + + <p><code>cvs update</code></p> + + <p>You can also update individual files by adding the filename to the command.</p> + + <p>Or, to include any new directories when updating, do:</p> + + <p><code>cvs update -d</code></p> + + <ul> + <li><a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC132";>More about the cvs update command</a></li> + + <li><a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC134";>More about CVS update output</a></li> + </ul> + + <h3><a id="cvstatus" name="cvstatus">Comparing your working files to the repository</a></h3> + + <p>Another way to determine whether all of your working files are in sync with the latest versions in the repository is with the command:</p> + + <p><code>cvstatus</code></p> + + <p>or for status on individual files:</p> + + <p><code>cvs status filename</code></p> + + <p>This comparison may return one of the following messages:</p> + + <dl> + <dt>Locally modified</dt> + + <dd>You have edited the file, and not yet committed your changes.</dd> + + <dt>Locally Added</dt> + + <dd>You have added the file with `add', and not yet committed your changes.</dd> + + <dt>Locally Removed</dt> + + <dd>You have removed the file with `remove', and not yet committed your changes.</dd> + + <dt>Needs Checkout</dt> + + <dd>Someone else has committed a newer revision to the repository. The name is slightly misleading; you will ordinarily use `update' rather than `checkout' to get that newer revision.</dd> + + <dt>Needs Patch</dt> + + <dd>Like Needs Checkout, but the CVS server will send a patch rather than the entire file. Sending a patch or sending an entire file accomplishes the same thing.</dd> + + <dt>Needs Merge</dt> + + <dd>Someone else has committed a newer revision to the repository, and you have also made modifications to the file.</dd> + + <dt>File had conflicts on merge</dt> + + <dd>This is like Locally Modified, except that a previous `update' command gave a conflict and CVS could not resolve the changes made. If you have not already done so, you need to <a href="#cvsresolving">resolve the conflict</a>.</dd> + + <dt>Unknown</dt> + + <dd>CVS doesn't know anything about this file. For example, you have created a new file and have not run `cvs add'.</dd> + </dl> + + <p>In general, a good rule of thumb is to make sure your working files are up to date with the repository <i>just before you commit your changes to a file</i>. The reason for this is that sometimes your commit may be unsuccessful, for example, you may be trying to commit from the wrong directory or perhaps another developer has committed changes to that same file after you checked it out of the repository or last updated it. Trying to commit your changes to an older version of the same file often causes conflicts when CVS tries to merge these. The result of your commit attempt under such circumstances is a somewhat daunting failure message about "dying gasps" from CVS. (Unfortunately, you don't find this out until <i>after</i> you've gone through the process of mentally composing and entering a pithy change log message.)</p> + + <p>To see the differences between your copy of a file and the latest version in the repository:</p> + + <p><code>cvs diff filename</code></p> + + <p><a href="http://cvsbook.red-bean.com/cvsbook.html#Finding_Out_What_You__And_Others__Did_--_update_And_diff";>More about comparing your work with the project repository</a></p> + + <h3><a id="otherdiff" name="otherdiff">Comparing versions of files <i>before</i> you commit (diff)</a></h3> + + <p>Perhaps you want to see the changes another developer has made to the same file <i>before</i> you commit your own changes. For example, suppose you are committing some very complex changes which you anticipate may conflict with another developer's work.</p> + + <p>In this case, a workable solution is to save off your working file under a different name (something like: "filename-new"). Then you can run the "<b>cvs update</b>" command and compare the latest version from the repository with your file before committing your changes. You can even compare the two files side-by-side using the following diff command:</p> + + <p><code>diff -y filename filename-new</code></p> + + <h3><a id="cvsmerging" name="cvsmerging">Merging your changes with other developers' changes</a></h3> + + <p>By giving the "<b>cvs update</b>" command, you are essentially telling CVS to merge the latest versions of files from the repository into your working copies.</p> + + <p>Sometimes, however, other modifications made to a file since you last updated do not mesh well with your version. Or, you've made changes that conflict with the repository version. CVS makes every attempt to resolve such conflicts automatically when you update and commit, but sometimes it cannot resolve everything. Conflicts within the file must be resolved by hand.</p> + + <h3><a id="cvsresolving" name="cvsresolving">Resolving merge conflicts</a></h3> + + <p>To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by <b>>>>>>></b> and <b><<<<<<<</B>. When CVS cannot resolve a conflict, it includes both verions of the affected line or sections inthe file, with the latest version usually first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revisions numbers. Then you can save the file and commit again.</b></p> + + <ul> + <li><a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_7.html#SEC40";>An example of a conflict</a></li> + + <li><a href="http://cvsbook.red-bean.com/cvsbook.html#Detecting_And_Resolving_Conflicts";>More about resolving conflicts</a></li> + </ul> + + <h3><a id="reverting" name="reverting">Revision history and reverting</a></h3> + + <p>Beyond the usefulness of being able to review a file's modification history using the "<b>cvs log</b>" command, those earlier file revisions can actually be restored as the most current revision (that is, restored to the "repository head") by the process of <i>reverting</i>. This becomes a particularly useful option if you need to return to an earlier point in a file's evolution for whatever reason, somewhat like being able to turn back the clock. When development projects experience broken builds or other problems, this becomes one of the most useful and powerful features of version control.</p> + + <p>A word of caution: it's easy to get confused by the terminology of "revisions" versus "versions." <i>Revisions</i> are specific updates to individual files, such 1.1, 1.2, 1.3. When you run the "cvs log filename" command, the results are all of that particular file's revision numbers. By contrast, <i>versions</i> are <b><i>sets</i></b> of file revisions that are tagged and named at a certain point in time. The confusion occurs because versions are sometimes named similarly to file revisions (1.0, 1.1, 1.2 etc.). But versions do not have to be named this way; they can be any set of characters the Project Owner designates, and probably should use a different numbering scheme.</p> + + <p>First, before you attempting to do any reverting, it's recommended that you examine the differences between the file version currently at the head of the repository and the version you want to revert to. The command to do this is:</p> + + <p><code>cvs diff -c -r version# -r version# filename</code></p> + + <p>This enables you to compare the two files before attempting to revert. The order for the file versions in this command is not critical, as long as you know can distinguish between the two versions.</p> + + <p>The command to revert requires strict observance in ordering the version numbers, however. Assuming you want to revert from a later version to an earlier version, the command is:</p> + + <p><code>cvs update -j later_version# -j earlier_version# filename</code></p> + + <p>Because there is more than one method for reverting, see also:<br /> + <a href="http://cvsbook.red-bean.com/cvsbook.html#Examining_And_Reverting_Changes";>More about reverting</a><br /> + <a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_16.html#SEC72";>More about revision history</a></p> + + <p>You should also know that reverting may result in "sticky tag" errors. These can be resolved using the following update command with a special switch:</p> + + <p><code>cvs update -dAP</code></p> + + <p>(<a href="http://cvsbook.red-bean.com/cvsbook.html#Getting_Snapshots__Dates_And_Tagging_";>What are sticky tag errors?</a>)</p> + <!-- + + <h3><a name="cvstips">Feedback on this document</a></h3> + <p> + The author of this help document has made every attempt to compile accurate, helpful information about using CVS for projects hosted on this site. If you think any content in the above document is wrong, inadequate, or something is just plain missing ... that's good. This is open source, so step up to the plate and contribute your suggestions for additions and improvements. + </p> --> + + <p>More CVS help: <a href="/nonav/docs/ddCVS_cvsmanaging.html">Managing project files and directories with command line CVS</a></p> + + <div class="courtesylinks"> + <p><a href="#toc">Top</a> | <a href="/nonav/servlets/HelpTOC">Help index</a></p> + </div> + </div> + </body> +</html> + + Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvsglossary.html ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvsglossary.html (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvsglossary.html Sat Apr 8 23:00:09 2017 @@ -0,0 +1,119 @@ +<!--#include virtual="/doctype.html" --> +<html> +<head> +<link href="/css/ooo.css" rel="stylesheet" type="text/css"> + +<TITLE>A version control glossary</TITLE> + +<!--#include virtual="/google-analytics.js" --> +<!--#include virtual="/scripts/entourage.js" --> +</head> +<body> +<!--#include virtual="/pl/brand.html" --> + <div id="topbara"> + <!--#include virtual="/pl/topnav.html" --> + <div id="breadcrumbsa"><a href="/">home</a> » <a href="/pl/">pl</a> » <a href="/pl/Archive/">Archive</a> » <a href="/pl/Archive/trans/">trans</a> » <a href="/pl/Archive/trans/docs/">docs</a> » <a href="/pl/Archive/trans/docs/orig/">orig</a></div> + </div> + <div id="clear"></div> + + + <div id="content"> + + + + +<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%"> + <TR> + <SPAN CLASS="Header">A version control glossary</SPAN> + +<P> +<SPAN CLASS="PlainText"><SPAN CLASS="PlainText"><B>CVS tool documents: Index</B> +<P> +<UL> +<DL> +<DT><A HREF="ddCVS.html">About source code version control with CVS</A> +<DT><B>You are here: A version control glossary +<UL> +<LI><A HREF="#whatis">What is version control?</A> +<LI><A HREF="#keyterms">Key terms in version control</A> +<LI><A HREF="#devcycle">The copy-modify-merge development cycle</A> +</UL></B> +<DD><A HREF="ddUsingCVS_command-line.html">Using command-line CVS to access project source files</A> +<DD><A HREF="ddCVS_cvsmanaging.html">Managing project files and directories with CVS</A> +<DT><A HREF="/servlets/HelpTOC">Back to main Help index</A> +</DL> +</UL> +<P> + +<HR NOSHADE SIZE=1> +<A NAME="whatis"></A><SPAN CLASS="InputHeader">What is version control?</SPAN> +<P> +A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them. In this way, version control keeps a historically accurate and retrievable log of a file's revisions. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network by merging their changes into the same source repository. +<P> + +<HR NOSHADE SIZE=1> +<A NAME="keyterms"></A><SPAN CLASS="InputHeader">Key terms in version control</SPAN> + <DL> +<DT><SPAN CLASS="PlainTextBold">Checking in a file or directory</SPAN> <DD>This copies your working directory back into the repository as a new version. + <P> + <DT><SPAN CLASS="PlainTextBold">Checking out files or directories</SPAN> <DD>This copies the latest revision of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it. + <P> + <DT><SPAN CLASS="PlainTextBold">Committing a file or directory</SPAN> <DD>This is the same as checking in a file or directory. Often version control users will say that they have "committed a change"; this means that they made changes to their working copies of files and committed these back to the repository. + <P> +<DT><SPAN CLASS="PlainTextBold">Conflict</SPAN> <DD>When two developers make changes to their working copies of the same file and commit them to the repository, their work may conflict. When this happens, CVS will detect the conflict and require someone to resolve resolve it before committing their changes. + <P> +<DT><SPAN CLASS="PlainTextBold">Merging</SPAN> <DD>Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple developers work at the same time (with no locks on files), and then incorporating their work into one combined version. Merging works well when two sets of changes are made to different lines in a files and can be easily combined. When changes to a file are made on the same line or lines, conflicts occur, requiring someone to edit the file manually before the changes can be committed to the source repository successfully. + <P> + + <DT><SPAN CLASS="PlainTextBold">Repository</SPAN> <DD>A shared database with the complete revision history of all files under version control. + <P> + <DT><SPAN CLASS="PlainTextBold">Resolving</SPAN> <DD>Conflicts within a file created by two developers attempting to commit conflicting changes must be addressed by manually editing the file. Someone must go through the file line by line to accept one set of changes and delete the other set. Files with conflicts cannot be committed into the source repository successfully until they are resolved. +<P> + <DT><SPAN CLASS="PlainTextBold">Revision</SPAN> <DD>A numbered draft of specific updates to individual files. Each time you edit a file and commit it back to the repository, the file's revision number increases. + <P> + <DT><SPAN CLASS="PlainTextBold">Version</SPAN> <DD>The numbering scheme used to identify <I>sets of files</I> that are tagged and named at a certain point in time. + <P> + <DT><SPAN CLASS="PlainTextBold">Workspace</SPAN> <DD>Your copies of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them. + <P> + </DL> + +<HR NOSHADE SIZE=1> +<A NAME="devcycle"></A><SPAN CLASS="InputHeader">The copy-modify-merge development cycle</SPAN> +<SPAN CLASS="PlainText"> +<P> +Because CVS is a vastly powerful tool, the learning curve might seem formidable. Certainly there are plenty of books and web sites offering comprehensive CVS knowledge bases (many good sources are referenced at the bottom of this site's main CVS page). However, it is not necessary to digest an entire tome to be able to incorporate CVS into your software development practices immediately and effectively. +<P> +CVS allows you to work within your own development cycle while keeping track of the project's overall development cycle: +<OL> +<LI>You begin working on a project by obtaining your own working copy of files, known as <I>checking out</I> the project repository or modules, individual groups of project source files. +<P> +<LI>You make your contributions to the project by modifying these files and creating new files. +<P> +This part of the cycle doesn't involve cvs directly. You modify your working copies of project files using a file editor on your local machine. You can save and compile your edited files to test how your changes affect the particular project module you are working in without affecting anyone else's work on those same project files. Nothing you do affects other project participants until you merge your changes into the project repository. +<P> +<LI>You test and tweak your latest changes in your own workspace to make sure these work without breaking or corrupting the overall project. +<P> +<LI>Finally, you contribute back or <I>check in</I> your changes to the main or "top" body of project files, merging your work with the most recent working version known in CVS terminology as the <I>head</I>. +<P> +Committing your changes to merge with other developers' work is the most powerful aspect of CVS, but that power also makes it the most critical aspect. It's possible to get confused and accidentally overwrite someone else's changes or your own. Your contributed changes invariably will conflict with someone else's at some point. Understanding how and when to update your working copies and how to resolve merge conflicts are two particularly critical aspects of using CVS in collaborative development projects. +</OL> +<P> +This <I>copy-modify-merge cycle</I> is repeated throughout the life of the project by all contributing developers. CVS enables everyone to work on project files simultaneously, to stay up to date on the latest changes contributed by others, and to test how their own changes affect the overall project without interrupting other developers' cycles. +<P> +If you are new to CVS, learn more at: +<P> +<A HREF="http://www.cvshome.org/new_users.html"; TARGET="_new">CVS for New Users</A> (an article)<BR> +<A HREF="http://cvsbook.red-bean.com/cvsbook.html#An_Overview_of_CVS"; TARGET="_new">An Overview of CVS</A> (from the online version of Karl Fogel's book <I>Open Source Development with CVS</I>) +<P> + +<HR NOSHADE SIZE=1> +<A HREF="/servlets/HelpTOC">Back to main Help index</A></P> + +</SPAN> +</TR> +</TABLE> + + </div> +<!--#include virtual="/footer.html" --> +</body> +</html> Added: websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvsglossary.html.en ============================================================================== --- websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvsglossary.html.en (added) +++ websites/staging/ooo-site/trunk/content/pl/Archive/trans/docs/orig/ddCVS_cvsglossary.html.en Sat Apr 8 23:00:09 2017 @@ -0,0 +1,138 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" +"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd";> + +<html xmlns="http://www.w3.org/1999/xhtml";> + <head> +<style type="text/css"> +/* <![CDATA[ */ @import "/branding/css/tigris.css"; /* ]]> */ +</style> + <script src="/branding/scripts/sc.js" type="text/javascript"></script> + <link rel="stylesheet" type="text/css" href="/branding/css/print.css" media="print" /> + + <title>Version control glossary</title> + </head> + + <body class="docs" onload="self.focus()"> + <div class="docs" id="ddcvscvsglossary"> + <h2>A version control glossary</h2> + + <div id="toc"> + <ul> + <li><strong><a href="/nonav/servlets/HelpTOC">Help index</a></strong></li> + </ul> + + <ul> + <li> + <a href="/nonav/docs/ddCVS.html">About source code version control with CVS</a> + + <ul> + <li> + A version control glossary + + <ul> + <li><a href="#whatis">What is version control?</a></li> + + <li><a href="#keyterms">Key terms in version control</a></li> + + <li><a href="#devcycle">The copy-modify-merge development cycle</a></li> + </ul> + </li> + + <li><a href="/nonav/docs/ddUsingCVS_command-line.html">Using command-line CVS to access project source files</a></li> + + <li><a href="/nonav/docs/ddCVS_cvsmanaging.html">Managing project files and directories with CVS</a></li> + </ul> + </li> + </ul> + </div> + + <h3><a id="whatis" name="whatis">What is version control?</a></h3> + + <p>A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them. In this way, version control keeps a historically accurate and retrievable log of a file's revisions. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network by merging their changes into the same source repository.</p> + + <h3><a id="keyterms" name="keyterms">Key terms in version control</a></h3> + + <dl> + <dt>Checking in a file or directory</dt> + + <dd>This copies your working directory back into the repository as a new version.</dd> + + <dt>Checking out files or directories</dt> + + <dd>This copies the latest revision of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it.</dd> + + <dt>Committing a file or directory</dt> + + <dd>This is the same as checking in a file or directory. Often version control users will say that they have "committed a change"; this means that they made changes to their working copies of files and committed these back to the repository.</dd> + + <dt>Conflict</dt> + + <dd>When two developers make changes to their working copies of the same file and commit them to the repository, their work may conflict. When this happens, CVS will detect the conflict and require someone to resolve resolve it before committing their changes.</dd> + + <dt>Merging</dt> + + <dd>Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple developers work at the same time (with no locks on files), and then incorporating their work into one combined version. Merging works well when two sets of changes are made to different lines in a files and can be easily combined. When changes to a file are made on the same line or lines, conflicts occur, requiring someone to edit the file manually before the changes can be committed to the source repository successfully.</dd> + + <dt>Repository</dt> + + <dd>A shared database with the complete revision history of all files under version control.</dd> + + <dt>Resolving</dt> + + <dd>Conflicts within a file created by two developers attempting to commit conflicting changes must be addressed by manually editing the file. Someone must go through the file line by line to accept one set of changes and delete the other set. Files with conflicts cannot be committed into the source repository successfully until they are resolved.</dd> + + <dt>Revision</dt> + + <dd>A numbered draft of specific updates to individual files. Each time you edit a file and commit it back to the repository, the file's revision number increases.</dd> + + <dt>Version</dt> + + <dd>The numbering scheme used to identify <i>sets of files</i> that are tagged and named at a certain point in time.</dd> + + <dt>Workspace</dt> + + <dd>Your copies of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them.</dd> + </dl> + + <h3><a id="devcycle" name="devcycle">The copy-modify-merge development cycle</a></h3> + + <p>Because CVS is a vastly powerful tool, the learning curve might seem formidable. Certainly there are plenty of books and web sites offering comprehensive CVS knowledge bases (many good sources are referenced at the bottom of this site's main CVS page). However, it is not necessary to digest an entire tome to be able to incorporate CVS into your software development practices immediately and effectively.</p> + + <p>CVS allows you to work within your own development cycle while keeping track of the project's overall development cycle:</p> + + <ol> + <li>You begin working on a project by obtaining your own working copy of files, known as <i>checking out</i> the project repository or modules, individual groups of project source files.</li> + + <li> + You make your contributions to the project by modifying these files and creating new files. + + <p>This part of the cycle doesn't involve cvs directly. You modify your working copies of project files using a file editor on your local machine. You can save and compile your edited files to test how your changes affect the particular project module you are working in without affecting anyone else's work on those same project files. Nothing you do affects other project participants until you merge your changes into the project repository.</p> + </li> + + <li>You test and tweak your latest changes in your own workspace to make sure these work without breaking or corrupting the overall project.</li> + + <li> + Finally, you contribute back or <i>check in</i> your changes to the main or "top" body of project files, merging your work with the most recent working version known in CVS terminology as the <i>head</i>. + + <p>Committing your changes to merge with other developers' work is the most powerful aspect of CVS, but that power also makes it the most critical aspect. It's possible to get confused and accidentally overwrite someone else's changes or your own. Your contributed changes invariably will conflict with someone else's at some point. Understanding how and when to update your working copies and how to resolve merge conflicts are two particularly critical aspects of using CVS in collaborative development projects.</p> + </li> + </ol> + + <p>This <i>copy-modify-merge cycle</i> is repeated throughout the life of the project by all contributing developers. CVS enables everyone to work on project files simultaneously, to stay up to date on the latest changes contributed by others, and to test how their own changes affect the overall project without interrupting other developers' cycles.</p> + + <p>If you are new to CVS, learn more at:</p> + + <ul> + <li><a href="http://www.cvshome.org/new_users.html";>CVS for New Users</a> (an article)</li> + + <li><a href="http://cvsbook.red-bean.com/cvsbook.html#An_Overview_of_CVS";>An Overview of CVS</a> (from the online version of Karl Fogel's book <i>Open Source Development with CVS</i>)</li> + </ul> + + <div class="courtesylinks"> + <p><a href="#toc">Top</a> | <a href="/nonav/servlets/HelpTOC">Help index</a></p> + </div> + </div> + </body> +</html> + +
