Index: articles/committers-guide/article.sgml =================================================================== --- articles/committers-guide/article.sgml (Revision 39185) +++ articles/committers-guide/article.sgml (Arbeitskopie) @@ -95,11 +95,12 @@ - ports/ CVS Root + ports/ Subversion + Root - pcvs.FreeBSD.org:/home/pcvs - (see also ). + svn+ssh://svn.FreeBSD.org/ports + (see also ). @@ -264,828 +265,22 @@ - - Version Control System Operations + + Subversion Primer 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 . + tree as of May 2008, the doc/www tree as of + May 2012 and the ports tree as of July 2012. + - 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. + There + is a list of things missing in Subversion when compared to CVS + . The notes at + might also be useful. - 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 - 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., - 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. - - - &os; CVS Repositories, Hosts and Directories - - - - - Repository - Host - Directory - - - - - - ports - pcvs.FreeBSD.org - /home/pcvs - - - - projects - projcvs.FreeBSD.org - /home/projcvs - - - -
- - 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 - 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. - 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 - 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. - - - 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 - 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. - - &a.des; also supplied the following mini - primer for CVS. - - - - Check out a module with the co or - checkout command. - - &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. - - - Useful <command>cvs checkout</command> - options - - - - - - Do not create empty directories - - - - - Check out a single level, no - subdirectories - - - - - Check out revision, branch or tag - rev - - - - - Check out the sources as they were on date - date - - - -
- - Practical FreeBSD examples: - - - - Check out the Tools module, - which corresponds to - ports/Tools: - - &prompt.user; cvs co Tools - - You now have a directory named - ports/Tools with subdirectories - portbuild, - scripts, and - CVS. - - - - 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 - subdirectories CVS and - scripts, etc. - - - - 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. - - - - Check out the Tools module as - 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. - - - - Check out the Tools module as - it was on March 25th, 2009: - - &prompt.user; cvs co -D'2009-03-25' Tools - - You will not be able to commit modifications. - - - - Check out the Tools module as - it was one week ago: - - &prompt.user; cvs co -D'last week' Tools - - You will not be able to commit modifications. - - - - Note that cvs stores metadata in subdirectories named - CVS. Similarly, Subversion stores - metadata in subdirectories named - .svn. - - Arguments to and - are sticky, which means cvs will remember them later, e.g., - when you do a cvs update. - - - - Check the status of checked-out files with the - status command. - - &prompt.user; cvs status shazam - - 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: - - - - - - Up-to-date - File is up-to-date and unmodified. - - - - Needs Patch - File is unmodified, but there is a newer - revision in the repository. - - - - Locally Modified - File is up-to-date, but modified. - - - - Needs Merge - 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. - - - - - - You will also see the local revision and date, - the revision number of the newest applicable version - (newest applicable because if you have a - sticky date, tag or branch, it may not be the actual newest - revision), and any sticky tags, dates or options. - - - - Once you have checked something out, you can update it - with the update command. - - &prompt.user; cvs update shazam - - This updates the file shazam or the - contents of the shazam 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. - - Useful options, in addition to those listed above for - checkout: - - - - - - - Check out any additional missing - directories. - - - - - Update to head of main branch. - - - - - - If 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. - - Theoretically, specifying HEAD as the - argument to will give you the same - result as , but that is just - theory. - - The option is useful if: - - - - somebody has added subdirectories to the module - you have checked out after you checked it out. - - - - you checked out with , and later - change your mind and want to check out the - subdirectories as well. - - - - you deleted some subdirectories and want to check - them all back out. - - - - Watch the output of the cvs - update with care. The letter in - front of each filename indicates what was done with - it: - - - - - - U - The file was updated without trouble. - - - - P - 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. - - - - C - The file had been modified, and was merged with - conflicts. - - - - - - 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. - - - - View differences between the local version and the - repository version with the diff - command. - - &prompt.user; cvs diff shazam - - shows you every modification you have made to the - shazam file or module. - - - Useful <command>cvs diff</command> options - - - - - - Uses the unified diff format. - - - - - Uses the context diff format. - - - - - Shows missing or added files. - - - -
- - You 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) - are context; some (preceded by a - sign) - 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 . - - - - View log entries with the log - command. - - &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 - 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 - 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. - - - - 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. - - Create the file, cvs add it, then - cvs commit it. - - Similarly, you can add new directories by creating them - and then cvs adding them. Note that you - do not need to commit directories. - - - - Remove obsolete files with the remove - command. - - Remove the file, then cvs rm it, then - cvs commit it. - - - - Commit with the commit or - checkin command. - - - Useful <command>cvs commit</command> options - - - - - - Force a commit of an unmodified file. - - - - - 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 notes at - might also be useful. Subversion is also described in-depth - in Version Control - with Subversion. - - - - Check out the head branch: - - &prompt.user; svn co svn+ssh://svn.freebsd.org/base/head /usr/src - - - - 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. - - Commit messages should be clear, concise and provide - a reasonable summary to give an indication of what was - changed and why. - - Commit messages should provide enough information to - enable a third party to decide if the change is relevant to - them and if they need to read the change itself. - - 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. - - Avoid committing style or whitespace fixes and - functionality fixes in one go. It makes merging difficult, - and also makes it harder to understand just what functional - changes were made. In the case of documentation files, it - can make the job of the translation teams more complicated, - as it becomes difficult for them to determine exactly what - content changes need to be translated. - - Avoid 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. - - Before committing, always: - - - - verify which branch you are committing to, using - svn status. This is only needed for - the src tree, as the other trees are not branched. - - - - 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. - - - - Additional tips and tricks: - - - - - You can place commonly used options in your - ~/.cvsrc, like this: - - cvs -z3 -diff -Nu -update -Pd -checkout -P - - This example says: - - - - always use compression level 3 when talking to a - remote server. This is a life-saver when working over a - slow connection. - - - - always use the (show added or - removed files) and (unified diff - format) options to &man.diff.1;. - - - - always use the (prune empty - directories) and (check out new - directories) options when updating. - - - - always use the (prune empty - directories) option when checking out. - - - - - - 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). - - textproc/cdiff - - Simply use it instead of &man.more.1; or - &man.less.1;: - - &prompt.user; cvs diff -Nu shazam | cdiff - - Alternatively some editors like &man.vim.1; (editors/vim) have color support - and when used as a pager with color syntax highlighting - switched on will highlight many types of file, including - diffs, patches, and CVS/RCS logs. - - &prompt.user; echo "syn on" >> ~/.vimrc -&prompt.user; cvs diff -Nu shazam | vim - -&prompt.user; cvs log shazam | vim - - - - - CVS is old, arcane, crufty and buggy, and sometimes - exhibits non-deterministic behavior which some claim as - proof that it is actually merely the Newtonian manifestation - of a sentient transdimensional entity. It is not humanly - possible to know its every quirk inside out, so do not be - afraid to ask the resident AI (&a.cvsadm;) for help. - - - - Do not leave the cvs commit command - in commit message editing mode for too long (more than - 2–3 minutes). It locks the directory you are working - with and will prevent other developers from committing into - the same directory. If you have to type a long commit - message, type it before executing cvs - commit and insert it into the commit message or - save it in a file before committing and use the - option of CVS to read the commit message - from that file, i.e., - - &prompt.user; vi logmsg -&prompt.user; cvs ci -F logmsg shazam - - This is the fastest way of passing a commit message to - CVS but you should be careful when editing the - logmsg file before the commit, because - CVS will not give you a chance to edit the message when you - do the actual commit. - - - - Speed up your CVS operation considerably by using a - persistent ssh connection to the repository machine. First, - put this configuration into your - ~/.ssh/config: - - Host pcvs.FreeBSD.org - ControlPath /home/user/.ssh/cvs.cpath -Host projcvs.FreeBSD.org - ControlPath /home/user/.ssh/cvs.cpath - - Now open the persistent connection to the - repoman: - - &prompt.user; ssh -fNM ncvs.FreeBSD.org - - The CVS commands should now respond faster, as they are - reusing existing connection with the repository. Note that - all the hostnames are case sensitive. - - - - - - Subversion Primer - Introduction @@ -1110,6 +305,11 @@ head/lang/htdocs/. + The &os; ports repository switched + from CVS to Subversion on July 14th, 2012. + The first real SVN commit is + rxxxxxx. + There are mechanisms in place to automatically merge changes back from the Subversion repository to the CVS one, so regular users should not notice @@ -1182,12 +382,19 @@ &prompt.user; svn checkout svn+ssh://svn.freebsd.org/doc/head /usr/doc + For the ports tree, use: + + &prompt.user; svn checkout svn+ssh://svn.freebsd.org/ports/head /usr/ports + Though the remaining examples in this document are written with the workflow of working with the src tree in mind, the underlying concepts are the same for working with the - doc tree. + doc and the ports + tree. + Ports related Subversion operations are listed in the + The above command will check out a @@ -1456,6 +663,40 @@ + + + &os; Ports Tree Branches and Layout + + In svn+ssh://svn.freebsd.org/ports, + ports refers repository root of the + ports tree. + + In general, most &os; port work will be done within + the head/ branch of the ports tree + which is the actual ports tree used to install software. + Some other key locations are: + + + + /branches/RELENG_n_n_n + which corresponds to + RELENG_n_n_n is used + to merge back security updates in preparation for a release. + + + + /tags/RELEASE_n_n_n + which corresponds to + RELEASE_n_n_n + represents a release tag of the ports tree. + + + /tags/RELEASE_n + _EOL represents the end of life tag of a + specific &os; branch. + + + @@ -1609,6 +850,13 @@ in a single operation: &prompt.user; svn commit lib/libfetch usr/bin/fetch + + There is also a commit wrapper for the ports tree + to handle the properties and sanity checking your + changes: + + &prompt.user; /usr/ports/Tools/scripts/psvn commit + @@ -1617,14 +865,17 @@ Before adding files, get a copy of auto-props.txt - and add it to ~/.subversion/config - according to the instructions in the file. If you added - something before you've read this, you may use - svn rm --keep-local for just added - files, fix your config file and re-add them again. The - initial config file is created when you first run a svn - command, even something as simple as svn - help. + (there is also a + ports tree specific version) and add it to + ~/.subversion/config according to + the instructions in the file. If you added something + before you've read this, you may use svn rm + --keep-local for just added files, fix your + config file and re-add them again. The initial config + file is created when you first run a svn command, even + something as simple as svn help. + As with CVS, files are added to a @@ -2724,6 +1975,9 @@ In commit logs etc., rev 179872 should be spelled r179872 as per convention. + Don't remove and re-add the same file in a single commit + as this will break the CVS exporter. + Speeding up checkouts and minimising network traffic is possible with the following recipe: @@ -4287,7 +3541,7 @@ - Remove the port's files via cvs remove. + Remove the port's files via svn remove. @@ -4329,20 +3583,20 @@ This is essentially the reverse of deleting a port. - Figure out when the port was removed. Use the ports - cvsweb - and then navigate to - category/portname/Attic/ . + Figure out when the port was removed. Use this + list + and then copy the last living revision of the port: + + &prompt.user; cd /usr/ports/category + + &prompt.user; svn cp 'svn+ssh://svn.freebsd.org/ports/category/portname/@{YYYY-MM-DD}' portname + + Pick a date that is before the removal but after the last true commit. - In the proper directory: -cvs update -D datespec. - - - Perform whatever changes are necessary to make the port work again. If it was deleted because the distfiles are no longer available you will need to volunteer to host them @@ -4350,7 +3604,8 @@ - cvs add the updated files. + svn add or svn remove + any appropriate files. @@ -4365,7 +3620,7 @@ - cvs commit these changes, preferably in + svn commit these changes, preferably in one step. @@ -4402,45 +3657,30 @@ - When do we not need a - repository copy? - - - - When there is no history to preserve. If a port is - added into a wrong category and is moved immediately, - it suffices to simply cvs remove the - old one and addport the new - one. - - - - - What do I need to do? - File a PR in GNATS, listing the - reasons for the repository copy request. Assign it to - portmgr and set state to - repocopy. In a few days, - portmgr will do - a repository copy from the old to the new location, and - reassign the PR back to you. Once everything is done, perform the - following: + Unlike with CVS a repo copy can be done by a committer + itself: - When a port has been repo copied: + Doing a repo copy: - Do a force commit on the files of the copied port, - stating repository copy was performed. + First make sure that you were using an up to + date portstree and the target directory does not + exist. + Use svn move or svn + copy to do the repo copy. + + + Upgrade the copied port to the new version. Remember to change the LATEST_LINK so there are no duplicate ports with the same name. @@ -4477,6 +3717,11 @@ ports/MOVED, if you remove the original port. + + + Commit all changes on one commit. A forced commit + is no longer needed with Subversion. + @@ -4954,7 +4199,7 @@ No, INDEX is no longer stored - in the CVS repository. The file can either be generated + in the SVN repository. The file can either be generated by running make index, or a pre-generated version can be downloaded with make fetchindex.