From owner-svn-doc-head@FreeBSD.ORG Wed May 30 00:05:46 2012 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EADC9106564A; Wed, 30 May 2012 00:05:46 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id D319B8FC08; Wed, 30 May 2012 00:05:46 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q4U05kIu012187; Wed, 30 May 2012 00:05:46 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id q4U05ksZ012185; Wed, 30 May 2012 00:05:46 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201205300005.q4U05ksZ012185@svn.freebsd.org> From: Glen Barber Date: Wed, 30 May 2012 00:05:46 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r38937 - head/en_US.ISO8859-1/articles/committers-guide X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:05:47 -0000 Author: gjb Date: Wed May 30 00:05:46 2012 New Revision: 38937 URL: http://svn.freebsd.org/changeset/doc/38937 Log: Whitespace cleanup: - Wrap long lines - Remove trailing/leading whitespace - Clean up superfluous empty lines Translators, please ignore. Modified: head/en_US.ISO8859-1/articles/committers-guide/article.sgml Modified: head/en_US.ISO8859-1/articles/committers-guide/article.sgml ============================================================================== --- head/en_US.ISO8859-1/articles/committers-guide/article.sgml Tue May 29 21:21:50 2012 (r38936) +++ head/en_US.ISO8859-1/articles/committers-guide/article.sgml Wed May 30 00:05:46 2012 (r38937) @@ -40,19 +40,21 @@ - This document provides information for the FreeBSD committer - community. All new committers should read this document before they - start, and existing committers are strongly encouraged to review it - from time to time. + This document provides information for the FreeBSD + committer community. All new committers should read this + document before they start, and existing committers are + strongly encouraged to review it from time to time. Almost all FreeBSD developers have commit rights to one or - more repositories. However, a few developers do not, and some of - the information here applies to them as well. (For instance, some - people only have rights to work with the Problem Report database). - Please see for more information. - - This document may also be of interest to members of the FreeBSD - community who want to learn more about how the project works. + more repositories. However, a few developers do not, and some + of the information here applies to them as well. (For + instance, some people only have rights to work with the + Problem Report database). Please see for more information. + + This document may also be of interest to members of the + FreeBSD community who want to learn more about how the project + works. @@ -71,14 +73,17 @@ Main Shell Host - freefall.FreeBSD.org + freefall.FreeBSD.org - src/ Subversion Root + src/ Subversion + Root - svn+ssh://svn.FreeBSD.org/base (see also ). - + svn+ssh://svn.FreeBSD.org/base + (see also ). doc/ Subversion @@ -86,18 +91,15 @@ svn+ssh://svn.FreeBSD.org/doc - (see also ). - + (see also ). ports/ CVS Root - - pcvs.FreeBSD.org:/home/pcvs - (see also ). - - + pcvs.FreeBSD.org:/home/pcvs + (see also ). @@ -105,23 +107,24 @@ developers (technically called all-developers), doc-developers, doc-committers, ports-developers, - ports-committers, src-developers, src-committers. - (Each project - repository has its own -developers and -committers mailing - lists. Archives for these lists may be found in files - /home/mail/repository-name-developers-archive - and - /home/mail/repository-name-committers-archive - on the FreeBSD.org - cluster.) - + ports-committers, src-developers, src-committers. (Each + project repository has its own -developers and + -committers mailing lists. Archives for these lists may + be found in files + /home/mail/repository-name-developers-archive + and + /home/mail/repository-name-committers-archive + on the FreeBSD.org + cluster.) - Core Team monthly reports + Core Team monthly + reports /home/core/public/monthly-reports - on the FreeBSD.org cluster. + on the FreeBSD.org + cluster. @@ -129,8 +132,8 @@ Ports Management Team monthly reports /home/portmgr/public/monthly-reports - on the FreeBSD.org cluster. - + on the FreeBSD.org + cluster. @@ -160,11 +163,13 @@ FreeBSD Project Internal Pages - FreeBSD - Project Hosts - - FreeBSD - Project Administrative Groups + FreeBSD Project + Hosts + + FreeBSD Project + Administrative Groups @@ -176,13 +181,13 @@ documentation, third party application ports infrastructure, and various maintained utilities. When FreeBSD commit bits are allocated, the areas of the tree where the bit may be used are - specified. Generally, the areas associated with a bit reflect who - authorized the allocation of the commit bit. Additional areas of - authority may be added at a later date: when this occurs, the - committer should follow normal commit bit allocation procedures for - that area of the tree, seeking approval from the appropriate entity - and possibly getting a mentor for that area for some period of time. - + specified. Generally, the areas associated with a bit reflect + who authorized the allocation of the commit bit. Additional + areas of authority may be added at a later date: when this + occurs, the committer should follow normal commit bit allocation + procedures for that area of the tree, seeking approval from the + appropriate entity and possibly getting a mentor for that area + for some period of time. @@ -214,19 +219,19 @@ - Commit bits allocated prior to the development of the notion of - areas of authority may be appropriate for use in many parts of the - tree. However, common sense dictates that a committer who has not - previously worked in an area of the tree seek review prior to - committing, seek approval from the appropriate responsible party, - and/or work with a mentor. Since the rules regarding code - maintenance differ by area of the tree, this is as much for the - benefit of the committer working in an area of less familiarity as - it is for others working on the tree. - - Committers are encouraged to seek review for their work as part - of the normal development process, regardless of the area of the - tree where the work is occurring. + Commit bits allocated prior to the development of the notion + of areas of authority may be appropriate for use in many parts + of the tree. However, common sense dictates that a committer + who has not previously worked in an area of the tree seek review + prior to committing, seek approval from the appropriate + responsible party, and/or work with a mentor. Since the rules + regarding code maintenance differ by area of the tree, this is + as much for the benefit of the committer working in an area of + less familiarity as it is for others working on the tree. + + Committers are encouraged to seek review for their work as + part of the normal development process, regardless of the area + of the tree where the work is occurring. Policy for <filename>doc/</filename> committer activity @@ -250,7 +255,7 @@ will involve a continuing of <quote>Approved by</quote> for some period.</para></listitem> - <listitem><para>"Approved by" is only acceptable from + <listitem><para>"Approved by" is only acceptable from non-mentored src committers -- mentored committers can provide a "Reviewed by" but not an "Approved by".</para></listitem> @@ -262,65 +267,69 @@ <sect1 id="vcs.operations"> <title>Version Control System Operations - It is assumed that you are already familiar with the basic operation - of the version control systems in use. Traditionally this was - CVS. Subversion is used for the src tree as - of May 2008 and the doc/www tree as of May - 2012. Subversion is covered in It is assumed that you are already familiar with the basic + operation of the version control systems in use. Traditionally + this was CVS. Subversion is used for the src + tree as of May 2008 and the doc/www tree as + of May 2012. Subversion is covered in . - The &a.cvsadm; are the owners of the repository and - are responsible for direct modification of it for the purposes of - cleanup or fixing some unfortunate abuse of the version control system by a committer. - Should you cause some repository accident, say a bad - import or a bad tag creation, mail the - responsible part of &a.cvsadm;, as stated in the table below, - (or call one of them) and report the problem. - For very important issues affecting the entire tree—not - just a specific area—you can contact the &a.cvsadm;. - Please do not contact the &a.cvsadm; for repocopies + The &a.cvsadm; are the owners of the + repository and are responsible for direct modification of it for + the purposes of cleanup or fixing some unfortunate abuse of the + version control system by a committer. Should you cause some + repository accident, say a bad import or a bad tag creation, + mail the responsible part of &a.cvsadm;, as stated in the table + below, (or call one of them) and report the problem. For very + important issues affecting the entire tree—not just a + specific area—you can contact the &a.cvsadm;. Please do + not contact the &a.cvsadm; for repocopies or other things that the more specific teams can handle. - The only ones able to directly fiddle the repository bits on the - repository hosts are the repomeisters. To enforce this, there are - no login shells available on the repository machines, except to - the repomeisters. - - Depending on the affected area of the repository, - you should send your request for a repocopy to one of the following email - addresses. Email sent to these addresses will be forwarded - to the appropriate repomeisters. - + The only ones able to directly + fiddle the repository bits on the repository hosts are the + repomeisters. To enforce this, there are no login shells + available on the repository machines, except to the + repomeisters. + + + Depending on the affected area of the repository, you + should send your request for a repocopy to one of the + following email addresses. Email sent to these addresses will + be forwarded to the appropriate repomeisters. + pcvs@ - regarding /home/pcvs, the ports repository - projcvs@ - regarding - /home/projcvs, the + projcvs@ - regarding /home/projcvs, the third party projects repository - The &os; repositories are currently split into two distinct parts, - namely ports and projects. - These are - combined under a single CVSROOT when distributed - via CVSup for the convenience of our users. - The src tree is automatically exported to - CVS for compatibility reasons only (e.g. + The &os; repositories are currently split into two distinct + parts, namely ports and + projects. These are combined under a single + CVSROOT when distributed via + CVSup for the convenience of our + users. The src tree is automatically + exported to CVS for compatibility reasons only (e.g. CVSup). The official src repository is not stored in CVS but in Subversion. The official and exported trees are not necessarily equal. The CVS repositories are hosted on the repository machines. - Currently, each of the repositories above reside on the same physical - machine, ncvs.FreeBSD.org, but to allow for - the possibility of placing each on a separate machine in the future, - there is a separate hostname for each that committers should use. - Additionally, each repository is stored in a separate directory. The - following table summarizes the situation. + Currently, each of the repositories above reside on the same + physical machine, ncvs.FreeBSD.org, but to allow for + the possibility of placing each on a separate machine in the + future, there is a separate hostname for each that committers + should use. Additionally, each repository is stored in a + separate directory. The following table summarizes the + situation. &os; CVS Repositories, Hosts and Directories @@ -351,62 +360,64 @@
CVS operations are done remotely by setting the - CVSROOT environment variable to the appropriate host - and top-level directory (for example, - pcvs.FreeBSD.org:/home/pcvs), - and - doing the appropriate check-out/check-in operations. Many committers - define aliases which expand to the correct cvs - invocation for the appropriate repository. For example, a &man.tcsh.1; - user may add the following to their .cshrc for this + CVSROOT environment variable to the appropriate + host and top-level directory (for example, pcvs.FreeBSD.org:/home/pcvs), + and doing the appropriate check-out/check-in operations. Many + committers define aliases which expand to the correct + cvs invocation for the appropriate + repository. For example, a &man.tcsh.1; user may add the + following to their .cshrc for this purpose: alias pcvs cvs -d user@pcvs.FreeBSD.org:/home/pcvs alias projcvs cvs -d user@projcvs.FreeBSD.org:/home/projcvs - This way they can do all CVS operations - locally and use Xcvs commit for committing - to the official CVS repository. + This way they can do all CVS operations locally and use + Xcvs commit for + committing to the official CVS repository. Refer to the &man.cvs.1; manual page for usage. - Please do not use - cvs checkout or - update with the official repository machine set - as the CVS Root for keeping your source tree up to date. - Remote CVS is not optimized for network distribution - and requires a big work/administrative overhead on the server side. - Please use our advanced cvsup distribution - method for obtaining the repository bits, and only do the actual + Please do not use cvs + checkout or update with the + official repository machine set as the CVS Root for keeping + your source tree up to date. Remote CVS is not optimized for + network distribution and requires a big work/administrative + overhead on the server side. Please use our advanced + cvsup distribution method for obtaining the + repository bits, and only do the actual commit operation on the repository host. - We provide an extensive cvsup replication network for this purpose, - as well as give access to cvsup-master if you - really need to stay current to the latest changes. - cvsup-master has got the horsepower to deal with - this, the repository master server does not. &a.kuriyama; is in - charge of cvsup-master. - + We provide an extensive cvsup replication network for this + purpose, as well as give access to + cvsup-master if you really need to stay + current to the latest changes. cvsup-master + has got the horsepower to deal with this, the repository + master server does not. &a.kuriyama; is in charge of + cvsup-master. If you need to use CVS add and delete operations in a manner that is - effectively a &man.mv.1; operation, then a repository - copy is in order rather than using CVS add and + effectively a &man.mv.1; operation, then a repository copy is in + order rather than using CVS add and delete. In a repository copy, a repomeister will copy the file(s) - to their new name and/or location and let you know when it is - done. The purpose of a repository copy is to preserve file - change history, or logs. We in the FreeBSD Project greatly - value the change history that a version control system gives to the project. - - CVS reference information, tutorials, and FAQs can be found at: - . - The information in Karl Fogel's - chapters from Open Source Development with CVS is also very - useful. + linkend="repomeisters">repomeister will copy the + file(s) to their new name and/or location and let you know when + it is done. The purpose of a repository copy is to preserve + file change history, or logs. We in the FreeBSD Project greatly + value the change history that a version control system gives to + the project. + + CVS reference information, tutorials, and FAQs can be found + at: . The + information in Karl Fogel's + chapters from Open Source Development with + CVS is also very useful. - &a.des; also supplied the following mini primer for - CVS. + &a.des; also supplied the following mini + primer for CVS. @@ -415,12 +426,15 @@ alias projcvs cvs -d user&prompt.user; cvs checkout shazam - This checks out a copy of the shazam module. If - there is no shazam module in the modules file, it looks for a - top-level directory named shazam instead. + This checks out a copy of the + shazam module. If there is no + shazam module in the modules file, it + looks for a top-level directory named + shazam instead. - Useful <command>cvs checkout</command> options + Useful <command>cvs checkout</command> + options @@ -431,7 +445,8 @@ alias projcvs cvs -d user - Check out a single level, no subdirectories + Check out a single level, no + subdirectories @@ -454,12 +469,14 @@ alias projcvs cvs -d user Check out the Tools module, - which corresponds to ports/Tools: + which corresponds to + ports/Tools: &prompt.user; cvs co Tools - You now have a directory named ports/Tools - with subdirectories portbuild, + You now have a directory named + ports/Tools with subdirectories + portbuild, scripts, and CVS. @@ -467,39 +484,42 @@ alias projcvs cvs -d user Check out the same files, but with full path: - &prompt.user; cvs co ports/Tools - You now have a directory named ports, - with subdirectories CVS and - Tools. The ports/Tools directory has + &prompt.user; cvs co ports/Tools + + You now have a directory named + ports, with subdirectories + CVS and Tools. + The ports/Tools directory has subdirectories CVS and scripts, etc. - Check out the directory Tools, but - none of the subdirectories: + Check out the directory Tools, + but none of the subdirectories: &prompt.user; cvs co -l Tools - You now have a directory named Tools - with just one subdirectory named - CVS. + You now have a directory named + Tools with just one subdirectory + named CVS. Check out the Tools module as - it was when support for &os; 5.X was dropped: - + it was when support for &os; 5.X was + dropped: &prompt.user; cvs co -rRELEASE_5_EOL Tools You will not be able to commit modifications, since - RELEASE_5_EOL is a point in time, not a branch. + RELEASE_5_EOL is a point in time, not + a branch. - Check out the Tools module as it was - on March 25th, 2009: + Check out the Tools module as + it was on March 25th, 2009: &prompt.user; cvs co -D'2009-03-25' Tools @@ -507,8 +527,8 @@ alias projcvs cvs -d user - Check out the Tools module as it was - one week ago: + Check out the Tools module as + it was one week ago: &prompt.user; cvs co -D'last week' Tools @@ -517,8 +537,8 @@ alias projcvs cvs -d user Note that cvs stores metadata in subdirectories named - CVS. - Similarly, Subversion stores metadata in subdirectories named + CVS. Similarly, Subversion stores + metadata in subdirectories named .svn. Arguments to and @@ -532,8 +552,8 @@ alias projcvs cvs -d user&prompt.user; cvs status shazam - This displays the status of the - file shazam or of every file in the + This displays the status of the file + shazam or of every file in the shazam directory. For every file, the status is given as one of: @@ -547,8 +567,8 @@ alias projcvs cvs -d user Needs Patch - File is unmodified, but there is a newer revision in - the repository. + File is unmodified, but there is a newer + revision in the repository. @@ -558,14 +578,15 @@ alias projcvs cvs -d user Needs Merge - File is modified, and there is a newer revision in the - repository. + File is modified, and there is a newer revision + in the repository. File had conflicts on merge - There were conflicts the last time this file was - updated, and they have not been resolved yet. + There were conflicts the last time this file + was updated, and they have not been resolved + yet. @@ -579,8 +600,8 @@ alias projcvs cvs -d user - Once you have checked something out, you can update it with the - update command. + Once you have checked something out, you can update it + with the update command. &prompt.user; cvs update shazam @@ -588,8 +609,8 @@ alias projcvs cvs -d usershazam directory to the latest version along the branch you checked out. If you checked out a point in time, it does nothing - unless the tags have moved in the repository or some other weird - stuff is going on. + unless the tags have moved in the repository or some other + weird stuff is going on. Useful options, in addition to those listed above for checkout: @@ -599,7 +620,8 @@ alias projcvs cvs -d user - Check out any additional missing directories. + Check out any additional missing + directories. @@ -613,14 +635,16 @@ alias projcvs cvs -d userIf you checked out a module with or , running cvs update with a different or - argument or with will select a new branch, - revision or date. The option clears all - sticky tags, dates or revisions whereas - and set new ones. + argument or with will select a new + branch, revision or date. The option + clears all sticky tags, dates or revisions whereas + and set new + ones. Theoretically, specifying HEAD as the - argument to will give you the same result - as , but that is just theory. + argument to will give you the same + result as , but that is just + theory. The option is useful if: @@ -632,8 +656,8 @@ alias projcvs cvs -d user you checked out with , and later - change your mind and want to check out the subdirectories - as well. + change your mind and want to check out the + subdirectories as well. @@ -643,8 +667,9 @@ alias projcvs cvs -d user Watch the output of the cvs - update with care. The letter in front of - each filename indicates what was done with it: + update with care. The letter in + front of each filename indicates what was done with + it: @@ -656,14 +681,15 @@ alias projcvs cvs -d user P - The file was updated without trouble (you will only see - this when working against a remote repository). + The file was updated without trouble (you will + only see this when working against a remote + repository). M - The file had been modified, and was merged without - conflicts. + The file had been modified, and was merged + without conflicts. @@ -675,37 +701,38 @@ alias projcvs cvs -d user - Merging is what happens if you check out a copy of - some file, modify it, then someone else commits a - change, and you run cvs update. CVS notices - that you have made local changes, and tries to merge your - changes with the changes between the version you originally - checked out and the one you updated to. If the changes are to - separate portions of the file, it will almost always work fine - (though the result might not be syntactically or semantically - correct). - - CVS will print an M in front of every locally modified - file even if there is no newer version in the repository, so - cvs update is handy for getting a summary - of what you have changed locally. + Merging is what happens if you check out a copy of some + file, modify it, then someone else commits a change, and you + run cvs update. CVS notices that you have + made local changes, and tries to merge your changes with the + changes between the version you originally checked out and + the one you updated to. If the changes are to separate + portions of the file, it will almost always work fine + (though the result might not be syntactically or + semantically correct). + + CVS will print an M in front of every + locally modified file even if there is no newer version in + the repository, so cvs update is handy + for getting a summary of what you have changed + locally. If you get a C, then your changes conflicted with the changes in the repository (the changes were to the same lines, or neighboring lines, or you changed the local file so much that cvs can not - figure out how to apply the repository's changes). You will have - to go through the file manually and resolve the conflicts; - they will be marked with rows of <, - = and > signs. For - every conflict, there will be a marker line with seven - < signs and the name of the file, - followed by a chunk of what your local file contained, - followed by a separator line with seven = - signs, followed by the corresponding chunk in the - repository version, followed by a marker line with seven - > signs and the revision number you - updated to. + figure out how to apply the repository's changes). You will + have to go through the file manually and resolve the + conflicts; they will be marked with rows of + <, = and + > signs. For every conflict, there + will be a marker line with seven < + signs and the name of the file, followed by a chunk of what + your local file contained, followed by a separator line with + seven = signs, followed by the + corresponding chunk in the repository version, followed by a + marker line with seven > signs and the + revision number you updated to. @@ -743,25 +770,25 @@ alias projcvs cvs -d userYou always want to use , since unified diffs are much easier to read than almost any other - diff format (in some circumstances, context diffs generated with - the option may be - better, but they are much bulkier). A unified diff consists of - a series of hunks. Each hunk begins with a line that starts - with two @ signs and specifies where in the - file the differences are and how many lines they span. This - is followed by a number of lines; some (preceded by a blank) + diff format (in some circumstances, context diffs generated + with the option may be better, but they + are much bulkier). A unified diff consists of a series of + hunks. Each hunk begins with a line that starts with two + @ signs and specifies where in the file + the differences are and how many lines they span. This is + followed by a number of lines; some (preceded by a blank) are context; some (preceded by a - sign) - are outtakes and some (preceded by a +) are - additions. + are outtakes and some (preceded by a +) + are additions. - You can also diff against a different version - than the one you checked out by specifying a version - with or as in - checkout or update, - or even view the diffs between two arbitrary versions - (without regard for what you have locally) by specifying - two versions with or - . + You can also diff against a different version than the + one you checked out by specifying a version with + or as in + checkout or update, or + even view the diffs between two arbitrary versions (without + regard for what you have locally) by specifying + two versions with + or . @@ -770,49 +797,52 @@ alias projcvs cvs -d user&prompt.user; cvs log shazam - If shazam is a file, this will print a - header with information about this file, such - as where in the repository this file is stored, which revision is - the HEAD for this file, what branches this file - is in, and any tags that are valid for this file. Then, for each - revision of this file, a log message is printed. This includes - the date and time of the commit, who did the commit, how many lines - were added and/or deleted, and finally the log message that the + If shazam is a file, this will + print a header with information about + this file, such as where in the repository this file is + stored, which revision is the HEAD for + this file, what branches this file is in, and any tags that + are valid for this file. Then, for each revision of this + file, a log message is printed. This includes the date and + time of the commit, who did the commit, how many lines were + added and/or deleted, and finally the log message that the committer who did the change wrote. - If shazam is a directory, then the log - information described above is printed for each file in the - directory in turn. Unless you give the to - log, the log for all subdirectories of - shazam is printed too, in a recursive - manner. - - Use the log command to view the history of - one or more files, as it is stored in the CVS repository. You can - even use it to view the log message of a specific revision, if you - add the to the + If shazam is a directory, then the + log information described above is printed for each file in + the directory in turn. Unless you give the + to log, the log for + all subdirectories of shazam is printed + too, in a recursive manner. + + Use the log command to view the + history of one or more files, as it is stored in the CVS + repository. You can even use it to view the log message of + a specific revision, if you add the + to the log command: &prompt.user; cvs log -r1.2 shazam This will print only the log message for revision - 1.2 of file shazam if it is - a file, or the log message for revision 1.2 of - each file under shazam if it is a - directory. + 1.2 of file shazam + if it is a file, or the log message for revision + 1.2 of each file under + shazam if it is a directory. - See who did what with the annotate command. - This command shows you each line of the specified file or - files, along with which user most recently changed that - line. + See who did what with the annotate + command. This command shows you each line of the specified + file or files, along with which user most recently changed + that line. &prompt.user; cvs annotate shazam - Add new files with the add command. + Add new files with the add + command. Create the file, cvs add it, then cvs commit it. @@ -823,7 +853,8 @@ alias projcvs cvs -d user - Remove obsolete files with the remove command. + Remove obsolete files with the remove + command. Remove the file, then cvs rm it, then cvs commit it. @@ -845,23 +876,24 @@ alias projcvs cvs -d user - Specify a commit message on the command line rather - than invoking an editor. + Specify a commit message on the command line + rather than invoking an editor.
- The following are some Subversion examples related to the - src repository. More (in-depth) information can be found in - the Subversion Primer at - and List of - things missing in Subversion when compared to CVS. + The following are some Subversion examples related to + the src repository. More (in-depth) information can be + found in the Subversion Primer at and List of + things missing in Subversion when compared to CVS. The notes at + url="http://people.freebsd.org/~peter/svn_notes.txt"> might also be useful. Subversion is also described in-depth - in Version Control with Subversion. + in Version Control + with Subversion. @@ -871,12 +903,12 @@ alias projcvs cvs -d user - Good commit messages are important. They tell others - why you did the changes you did, not just right here and now, + Good commit messages are important. They tell others why + you did the changes you did, not just right here and now, but months or years from now when someone wonders why some - seemingly illogical or inefficient piece of code sneaked into - your source file. It is also an invaluable aid to deciding - which changes to MFC and which not to MFC. + seemingly illogical or inefficient piece of code sneaked + into your source file. It is also an invaluable aid to + deciding which changes to MFC and which not to MFC. Commit messages should be clear, concise and provide a reasonable summary to give an indication of what was @@ -887,8 +919,9 @@ alias projcvs cvs -d user Avoid committing several unrelated changes in one go. It - makes merging difficult, and also makes it harder to determine - which change is the culprit if a bug crops up. + makes merging difficult, and also makes it harder to + determine which change is the culprit if a bug crops + up. Avoid committing style or whitespace fixes and functionality fixes in one go. It makes merging difficult, @@ -900,7 +933,8 @@ alias projcvs cvs -d userAvoid committing changes to multiple files in one go with a generic, vague message. Instead, commit each file (or - small, related groups of files) with tailored commit messages. + small, related groups of files) with tailored commit + messages. Before committing, always: @@ -912,15 +946,17 @@ alias projcvs cvs -d user - review your diffs, using the diff command of the version control system. + review your diffs, using the diff command of the + version control system. Also, ALWAYS specify which files to commit explicitly on - the command line, so you do not accidentally commit other files - than the ones you intended — a commit operation - without any arguments usually will commit every modification in your - current working directory and every subdirectory. + the command line, so you do not accidentally commit other + files than the ones you intended — a commit operation + without any arguments usually will commit every modification + in your current working directory and every + subdirectory. @@ -967,23 +1003,26 @@ checkout -P Use Eivind Eklund's cdiff script to - view unidiffs. It is a wrapper for &man.less.1; that adds ANSI - color codes to make hunk headers, outtakes and additions stand - out; context and garbage are unmodified. It also expands tabs - properly (tabs often look wrong in diffs because of the extra - character in front of each line). + view unidiffs. It is a wrapper for &man.less.1; that adds *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***