diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -62,7 +62,7 @@ |`ssh://git@gitrepo.FreeBSD.org/doc.git` (see also <>). |`_ports/_` Subversion Root -|`svn+ssh://repo.FreeBSD.org/ports` (see also <>). +|`ssh://git@gitrepo.FreeBSD.org/ports.git` (see also <>). |_Internal Mailing Lists_ |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 can be found in the files [.filename]#/local/mail/repository-name-developers-archive# and [.filename]#/local/mail/repository-name-committers-archive# on the `FreeBSD.org` cluster.) @@ -463,22 +463,15 @@ Again, the git-bisect manual (linked above) is a good resource for when things go wrong or for unusual cases. ==== Ports Considerations -The ports migration is in progress, and some of this section may change before that is complete. The ports tree operates the same way. The branch names are different and the repositories are in different locations. The legacy GitHub mirror is at https://github.com/freebsd/freebsd-ports.git . -The canonical cgit mirror is https://cgit-beta.freebsd.org/ports.git . -The production git repo will be https://git.freebsd.org/ports.git and ssh://anongit@git.FreeBSD.org/ports.git (or anongit@git.FreeBSD.org:ports.git) when the time comes. +The canonical cgit mirror is https://cgit.freebsd.org/ports.git . +The production git repo is https://git.freebsd.org/ports.git and ssh://anongit@git.FreeBSD.org/ports.git (or anongit@git.FreeBSD.org:ports.git). The 'current' branches are 'master' (legacy) and 'main' (new) respectively. -The quarterly branches are named the same as in FreeBSD's svn repo. - -[NOTE] -==== -The cgit repo for ports is considered beta. -The git hashes may change as problems are found in the conversion prior to the cutover. -==== +The quarterly branches are named 'branches/yyyyQn'. ==== Managing Local Changes This section addresses tracking local changes. @@ -2157,15 +2150,16 @@ LANG above is the two character language code. All document source is encoded using Unicode. -[[svn-getting-started-ports-layout]] +[[git-getting-started-ports-layout]] ==== FreeBSD Ports Tree Branches and Layout -In `svn+ssh://repo.freebsd.org/ports`, _ports_ refers to the repository root of the ports tree. +In `ssh://gitrepo.freebsd.org/ports.git`, _ports_ refers to the repository root of the ports tree. -In general, most FreeBSD port work will be done within the [.filename]#head/# branch of the ports tree which is the actual ports tree used to install software. +In general, most FreeBSD port work will be done within the `main` 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. +* /branches/yyyyQn which represents the currently quarterly branch (e.g. 2021Q2) which receives mostly security and bugfixes. +* /branches/RELENG_n_n_n which corresponds to `RELENG_n_n_n` is used to merge back security updates in preparation for a release. This branch was only used before the quarterly ports branches existed. * /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 FreeBSD branch. @@ -2299,13 +2293,6 @@ % svn commit lib/libfetch usr/bin/fetch .... -There is also a commit wrapper for the ports tree to handle the properties and sanity checking the changes: - -[source,shell] -.... -% /usr/ports/Tools/scripts/psvn commit -.... - [[svn-daily-use-adding-and-removing]] ==== Adding and Removing Files @@ -4142,7 +4129,7 @@ + [.procedure] ==== -* Remove the port's files and directory with `svn remove`. +* Remove the port's files and directory with `git rm`. * Remove the `SUBDIR` listing of the port in the parent directory [.filename]#Makefile#. * Add an entry to [.filename]#ports/MOVED#. * Search for entries in [.filename]#ports/security/vuxml/vuln.xml# and adjust them accordingly. In particular, check for previous packages with the new name which version could include the new port. @@ -4196,43 +4183,7 @@ . `svn commit` these changes, preferably in one step. ==== -[TIP] -==== -The `addport` script mentioned in <> now detects when the port to add has previously existed, and attempts to handle all except the `ports/LEGAL` step automatically. -==== - -[[ports-qa-repocopies]] -=== Repository Copies - -[[ports-qa-repocopy-when]] -==== When do we need a repository copy? - -When you want to add a port that is related to any port that is already in the tree in a separate directory, you have to do a repository copy. -Here related means it is a different version or a slightly modified version. -Examples are [.filename]#print/ghostscript*# (different versions) and [.filename]#x11-wm/windowmaker*# (English-only and internationalized version). - -Another example is when a port is moved from one subdirectory to another, or when the name of a directory must be changed because the authors renamed their software even though it is a descendant of a port already in a tree. - -[[ports-qa-repocopy-how]] -==== What do I need to do? - -With Subversion, a repo copy can be done by any committer: - -* Doing a repo copy: - -[.procedure] -==== -. Verify that the target directory does not exist. -. Use `svn up` to make certain the original files, directories, and checkout information is current. -. Use `svn move` or `svn copy` to do the repo copy. -. Upgrade the copied port to the new version. Remember to add or change the `PKGNAMEPREFIX` or `PKGNAMESUFFIX` so there are no duplicate ports with the same name. In some rare cases it may be necessary to change the `PORTNAME` instead of adding `PKGNAMEPREFIX` or `PKGNAMESUFFIX`, but this is only done when it is really needed — for example, using an existing port as the base for a very similar program with a different name, or upgrading a port to a new upstream version which actually changes the distribution name, like the transition from [.filename]#textproc/libxml# to [.filename]#textproc/libxml2#. In most cases, adding or changing `PKGNAMEPREFIX` or `PKGNAMESUFFIX` suffices. -. Add the new subdirectory to the `SUBDIR` listing in the parent directory [.filename]#Makefile#. You can run make checksubdirs in the parent directory to check this. -. If the port changed categories, modify the CATEGORIES line of the port's [.filename]#Makefile# accordingly -. Add an entry to [.filename]#ports/MOVED#, if you remove the original port. -. Commit all changes on one commit. -==== - -* When removing a port: +* When (re)moving a port: [.procedure] ==== @@ -4328,106 +4279,17 @@ [[ports-qa-misc-commit-mfh]] ==== What is the procedure for merging commits to the quarterly branch? -A script is provided to automate merging a specific commit: [.filename]#ports/Tools/scripts/mfh#. It is used as follows: - -[source,shell] -.... -% /usr/ports/Tools/scripts/mfh 380362 - U 2015Q1 -Checked out revision 380443. -A 2015Q1/security -Updating '2015Q1/security/rubygem-sshkit': -A 2015Q1/security/rubygem-sshkit -A 2015Q1/security/rubygem-sshkit/Makefile -A 2015Q1/security/rubygem-sshkit/distinfo -A 2015Q1/security/rubygem-sshkit/pkg-descr -Updated to revision 380443. ---- Merging r380362 into '2015Q1': -U 2015Q1/security/rubygem-sshkit/Makefile -U 2015Q1/security/rubygem-sshkit/distinfo ---- Recording mergeinfo for merge of r380362 into '2015Q1': - U 2015Q1 ---- Recording mergeinfo for merge of r380362 into '2015Q1/security': - G 2015Q1/security ---- Eliding mergeinfo from '2015Q1/security': - U 2015Q1/security ---- Recording mergeinfo for merge of r380362 into '2015Q1/security/rubygem-sshkit': - G 2015Q1/security/rubygem-sshkit ---- Eliding mergeinfo from '2015Q1/security/rubygem-sshkit': - U 2015Q1/security/rubygem-sshkit - M 2015Q1 -M 2015Q1/security/rubygem-sshkit/Makefile -M 2015Q1/security/rubygem-sshkit/distinfo -Index: 2015Q1/security/rubygem-sshkit/Makefile -=================================================================== ---- 2015Q1/security/rubygem-sshkit/Makefile (revision 380443) -+++ 2015Q1/security/rubygem-sshkit/Makefile (working copy) -@@ -2,7 +2,7 @@ - # $FreeBSD$ - - PORTNAME= sshkit --PORTVERSION= 1.6.1 -+PORTVERSION= 1.7.0 - CATEGORIES= security rubygems - MASTER_SITES= RG - -Index: 2015Q1/security/rubygem-sshkit/distinfo -=================================================================== ---- 2015Q1/security/rubygem-sshkit/distinfo (revision 380443) -+++ 2015Q1/security/rubygem-sshkit/distinfo (working copy) -@@ -1,2 +1,2 @@ --SHA256 (rubygem/sshkit-1.6.1.gem) = 8ca67e46bb4ea50fdb0553cda77552f3e41b17a5aa919877d93875dfa22c03a7 --SIZE (rubygem/sshkit-1.6.1.gem) = 135680 -+SHA256 (rubygem/sshkit-1.7.0.gem) = 90effd1813363bae7355f4a45ebc8335a8ca74acc8d0933ba6ee6d40f281a2cf -+SIZE (rubygem/sshkit-1.7.0.gem) = 136192 -Index: 2015Q1 -=================================================================== ---- 2015Q1 (revision 380443) -+++ 2015Q1 (working copy) - -Property changes on: 2015Q1 -___________________________________________________________________ -Modified: svn:mergeinfo - Merged /head:r380362 -Do you want to commit? (no = start a shell) [y/n] -.... - -At that point, the script will either open a shell for you to fix things, or open your text editor with the commit message all prepared and then commit the merge. - -The script assumes that you can connect to `repo.FreeBSD.org` with SSH directly, so if your local login name is different than your FreeBSD cluster account, you need a few lines in your [.filename]#~/.ssh/config#: - -[.programlisting] -.... -Host *.freebsd.org - User freebsd-login -.... - -[TIP] -==== -The script is also able to merge more than one revision at a time. -If there have been other updates to the port since the branch was created that have not been merged because they were not security related. -Add the different revisions in the order they were committed on the `mfh` line. -The new commit log message will contain the combined log messages from all the original commits. -These messages must be edited to show what is actually being done with the new commit. - +Merging commits to the quarterly branch is very similar to MFC'ing a commit in the src repository, so basically: [source,shell] .... -% /usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728 +% git checkout 2021Q2 +% git cherry-pick -x $HASH +(verify everything is OK, for example by doing a build test) +% git push .... -==== - -[NOTE] -==== -The mfh script can also take an optional first argument, the branch where the merge is being done. -Only the latest quarterly branch is supported, so specifying the branch is discouraged. -To be safe, the script will give a warning if the quarterly branch is not the latest: -[source,shell] -.... -% /usr/ports/Tools/scripts/mfh 2016Q1 r407208 r407713 -/!\ The latest branch is 2016Q2, do you really want to commit to 2016Q1? [y/n] -.... -==== +where '$HASH' is the hash of the commit you want to copy over to the quarterly branch. +The -x parameter ensures the hash '$HASH' of the main branch is included in the new commit message of the quarterly branch. [[ports-qa-new-category]] === Creating a New Category diff --git a/documentation/content/en/articles/problem-reports/_index.adoc b/documentation/content/en/articles/problem-reports/_index.adoc --- a/documentation/content/en/articles/problem-reports/_index.adoc +++ b/documentation/content/en/articles/problem-reports/_index.adoc @@ -100,7 +100,7 @@ (This is vital information if you are upgrading from one version to another-especially if you are upgrading to the FreeBSD-CURRENT branch). + However, if the problem is in something that was installed as a part of the FreeBSD Ports Collection, you should refer to [.filename]#/usr/ports/UPDATING# (for individual ports) or [.filename]#/usr/ports/CHANGES# (for changes that affect the entire Ports Collection). -https://svnweb.freebsd.org/ports/head/UPDATING?view=log[https://svnweb.freebsd.org/ports/head/UPDATING?view=log] and https://svnweb.freebsd.org/ports/head/CHANGES?view=log[https://svnweb.freebsd.org/ports/head/CHANGES?view=log] are also available via svnweb. +https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] and https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/tree/CHANGES] are also available via cgit. [[pr-writing]] == Writing the Problem Report @@ -117,7 +117,7 @@ * _If you are a maintainer, say so._ If you are maintaining a part of the source code (for instance, an existing port), you definitely should set the "Class" of your PR to `maintainer-update`. This way any committer that handles your PR will not have to check. * _Be specific._ The more information you supply about what problem you are having, the better your chance of getting a response. -** Include the version of FreeBSD you are running (there is a place to put that, see below) and on which architecture. You should include whether you are running from a release (e.g., from a CD-ROM or download), or from a system maintained by Subversion (and, if so, what revision number you are at). If you are tracking the FreeBSD-CURRENT branch, that is the very first thing someone will ask, because fixes (especially for high-profile problems) tend to get committed very quickly, and FreeBSD-CURRENT users are expected to keep up. +** Include the version of FreeBSD you are running (there is a place to put that, see below) and on which architecture. You should include whether you are running from a release (e.g., from a CD-ROM or download), or from a system maintained by Git (and, if so, what hash and branch you are at). If you are tracking the FreeBSD-CURRENT branch, that is the very first thing someone will ask, because fixes (especially for high-profile problems) tend to get committed very quickly, and FreeBSD-CURRENT users are expected to keep up. ** Include which global options you have specified in your [.filename]#make.conf#, [.filename]#src.conf#, and [.filename]#src-env.conf#. Given the infinite number of options, not every combination may be fully supported. ** If the problem can be reproduced easily, include information that will help a developer to reproduce it themselves. If a problem can be demonstrated with specific input then include an example of that input if possible, and include both the actual and the expected output. If this data is large or cannot be made public, then do try to create a minimal file that exhibits the same issue and that can be included within the PR. ** If this is a kernel problem, then be prepared to supply the following information. (You do not have to include these by default, which only tends to fill up the database, but you should include excerpts that you think might be relevant): @@ -152,8 +152,8 @@ [[pr-writing-attaching-patches]] == Attaching Patches or Files -When attaching a patch, be sure to use either `svn diff` or man:diff[1] with the `-u` option to create a unified diff and make sure to specify the SVN revision number of the repository against which you modified files, so the developers who read your report will be able to apply them easily. -For problems with the kernel or the base utilities, a patch against FreeBSD-CURRENT (the HEAD Subversion branch) is preferred since all new code should be applied and tested there first. +When attaching a patch, be sure to use either `git diff` or man:diff[1] with the `-u` option to create a unified diff and make sure to specify the Git hash and branch of the repository against which you modified files, so the developers who read your report will be able to apply them easily. +For problems with the kernel or the base utilities, a patch against FreeBSD-CURRENT (the main Git branch) is preferred since all new code should be applied and tested there first. After appropriate or substantial testing has been done, the code will be merged/migrated to the FreeBSD-STABLE branch. If you attach a patch inline, instead of as an attachment, note that the most common problem by far is the tendency of some email programs to render tabs as spaces, which will completely ruin anything intended to be part of a Makefile. @@ -249,7 +249,7 @@ * Find the relevant FreeBSD mailing list for the problem report from the link:{handbook}#eresources-mail[list in the Handbook] and send a message to that list asking about assistance or comments on the problem report. * Join the relevant IRC channels. A partial listing is here: https://wiki.freebsd.org/IrcChannels[]. Inform the people in that channel about the problem report and ask for assistance. Be patient and stay in the channel after posting, so that the people from different time zones around the world have a chance to catch up. -* Find committers interested in the problem that was reported. If the problem was in a particular tool, binary, port, document, or source file, check the http://svnweb.FreeBSD.org[SVN Repository]. Locate the last few committers who made substantive changes to the file, and try to reach them via IRC or email. A list of committers and their emails can be found in the link:{contributors}[Contributors to FreeBSD] article. +* Find committers interested in the problem that was reported. If the problem was in a particular tool, binary, port, document, or source file, check the https://cgit.FreeBSD.org[Git Repository]. Locate the last few committers who made substantive changes to the file, and try to reach them via IRC or email. A list of committers and their emails can be found in the link:{contributors}[Contributors to FreeBSD] article. Remember that these people are volunteers, just like maintainers and users, so they might not be immediately available to assist with the problem report. Patience and consistency in the follow-ups is highly advised and appreciated. diff --git a/documentation/content/en/books/handbook/cutting-edge/_index.adoc b/documentation/content/en/books/handbook/cutting-edge/_index.adoc --- a/documentation/content/en/books/handbook/cutting-edge/_index.adoc +++ b/documentation/content/en/books/handbook/cutting-edge/_index.adoc @@ -656,7 +656,7 @@ === Updating the Source FreeBSD source code is located in [.filename]#/usr/src/#. -The preferred method of updating this source is through the Subversion version control system. +The preferred method of updating this source is through the Git version control system. Verify that the source code is under version control: [source,shell] diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc --- a/documentation/content/en/books/handbook/mirrors/_index.adoc +++ b/documentation/content/en/books/handbook/mirrors/_index.adoc @@ -427,19 +427,19 @@ [[git-install]] === Installation -Git can be installed from the Ports Collection: +Git can be installed as a package: [source,shell] .... -# cd /usr/ports/devel/git -# make install clean +# pkg install git .... -Git can also be installed as a package: +Git can also be installed from the Ports Collection: [source,shell] .... -# pkg install git +# cd /usr/ports/devel/git +# make install clean .... [[git-usage]] @@ -706,10 +706,11 @@ [[svn-intro]] === Introduction -As of July 2012, FreeBSD uses Subversion as the only version control system for storing all of FreeBSD's Ports Collection. As of December 2020, FreeBSD uses git as the primary version control system for storing all of FreeBSD's source code and documentation. Changes from the git repo on the `stable/11`, `stable/12` and related releng branches are exported to the subversion repository. This export will continue through the life of these branches. +From July 2012 to March 2021, FreeBSD used Subversion as the only version control system for storing all of FreeBSD's Ports Collection. +As of April 2021, FreeBSD uses git as the only version control system for storing all of FreeBSD's Ports Collection. [NOTE] ==== @@ -778,7 +779,7 @@ Checkout over an existing non-`svn` directory can cause conflicts between the existing files and those brought in from the repository. ==== -Subversion uses URLs to designate a repository, taking the form of _protocol://hostname/path_. The first component of the path is the FreeBSD repository to access. There are three different repositories, `base` for the FreeBSD base system source code, `ports` for the Ports Collection, and `doc` for documentation. For example, the URL `https://svn.FreeBSD.org/ports/head/` specifies the main branch of the ports repository, using the `https` protocol. +Subversion uses URLs to designate a repository, taking the form of _protocol://hostname/path_. The first component of the path is the FreeBSD repository to access. There are three different repositories, `base` for the FreeBSD base system source code, `ports` for the Ports Collection, and `doc` for documentation. For example, the URL `https://svn.FreeBSD.org/base/head/` specifies the main branch of the ports repository, using the `https` protocol. A checkout from a given repository is performed with a command like this: @@ -793,11 +794,11 @@ * _branch_ depends on the repository used. `ports` and `doc` are mostly updated in the `head` branch, while `base` maintains the latest version of -CURRENT under `head` and the respective latest versions of the -STABLE branches under `stable/9` (9._x_) and `stable/10` (10._x_). * _lwcdir_ is the target directory where the contents of the specified branch should be placed. This is usually [.filename]#/usr/ports# for `ports`, [.filename]#/usr/src# for `base`, and [.filename]#/usr/doc# for `doc`. -This example checks out the Ports Collection from the FreeBSD repository using the HTTPS protocol, placing the local working copy in [.filename]#/usr/ports#. If [.filename]#/usr/ports# is already present but was not created by `svn`, remember to rename or delete it before the checkout. +This example checks out the Source Tree from the FreeBSD repository using the HTTPS protocol, placing the local working copy in [.filename]#/usr/src#. If [.filename]#/usr/src# is already present but was not created by `svn`, remember to rename or delete it before the checkout. [source,shell] .... -# svn checkout https://svn.FreeBSD.org/ports/head /usr/ports +# svn checkout https://svn.FreeBSD.org/base/head /usr/src .... Because the initial checkout must download the full branch of the remote repository, it can take a while. Please be patient. @@ -813,7 +814,7 @@ [source,shell] .... -# svn update /usr/ports +# svn update /usr/src .... The update is much quicker than a checkout, only transferring files that have changed. diff --git a/documentation/content/en/books/handbook/ports/_index.adoc b/documentation/content/en/books/handbook/ports/_index.adoc --- a/documentation/content/en/books/handbook/ports/_index.adoc +++ b/documentation/content/en/books/handbook/ports/_index.adoc @@ -610,40 +610,40 @@ .... **** -[[ports-using-subversion-method]] +[[ports-using-git-method]] [.procedure] **** -*Procedure: Subversion Method* +*Procedure: Git Method* -If more control over the ports tree is needed or if local changes need to be maintained, Subversion can be used to obtain the Ports Collection. Refer to link:{committers-guide}#subversion-primer[the Subversion Primer] for a detailed description of Subversion. +If more control over the ports tree is needed or if local changes need to be maintained, Git can be used to obtain the Ports Collection. Refer to link:{committers-guide}#git-primer[the Git Primer] for a detailed description of Git. -. Subversion must be installed before it can be used to check out the ports tree. If a copy of the ports tree is already present, install Subversion like this: +. Git must be installed before it can be used to check out the ports tree. If a copy of the ports tree is already present, install Git like this: + [source,shell] .... -# cd /usr/ports/devel/subversion +# cd /usr/ports/devel/git # make install clean .... + -If the ports tree is not available, or pkg is being used to manage packages, Subversion can be installed as a package: +If the ports tree is not available, or pkg is being used to manage packages, Git can be installed as a package: + [source,shell] .... -# pkg install subversion +# pkg install git .... + . Check out a copy of the ports tree: + [source,shell] .... -# svn checkout https://svn.FreeBSD.org/ports/head /usr/ports +# git clone https://git.FreeBSD.org/ports.git /usr/ports .... + -. As needed, update [.filename]#/usr/ports# after the initial Subversion checkout: +. As needed, update [.filename]#/usr/ports# after the initial Git checkout: + [source,shell] .... -# svn update /usr/ports +# git -C /usr/ports pull .... **** @@ -806,7 +806,7 @@ Over time, newer versions of software become available in the Ports Collection. This section describes how to determine which software can be upgraded and how to perform the upgrade. -To determine if newer versions of installed ports are available, ensure that the latest version of the ports tree is installed, using the updating command described in either <> or <>. On FreeBSD 10 and later, or if the system has been converted to pkg, the following command will list the installed ports which are out of date: +To determine if newer versions of installed ports are available, ensure that the latest version of the ports tree is installed, using the updating command described in either <> or <>. On FreeBSD 10 and later, or if the system has been converted to pkg, the following command will list the installed ports which are out of date: [source,shell] .... @@ -1049,7 +1049,7 @@ [source,shell] .... -# poudriere ports -c -p local -m svn+https +# poudriere ports -c -p local -m git+https [00:00:00] Creating local fs at /poudriere/ports/local... done [00:00:00] Checking out the ports tree... done .... diff --git a/documentation/content/en/books/porters-handbook/keeping-up/chapter.adoc b/documentation/content/en/books/porters-handbook/keeping-up/chapter.adoc --- a/documentation/content/en/books/porters-handbook/keeping-up/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/keeping-up/chapter.adoc @@ -40,10 +40,10 @@ FreshPorts also has a sanity test feature which automatically tests each commit to the FreeBSD ports tree. If subscribed to this service, a committer will receive notifications of any errors which FreshPorts detects during sanity testing of their commits. -[[svnweb]] +[[cgit]] == The Web Interface to the Source Repository -It is possible to browse the files in the source repository by using a web interface. Changes that affect the entire port system are now documented in the http://svnweb.FreeBSD.org/ports/head/CHANGES[CHANGES] file. Changes that affect individual ports are now documented in the http://svnweb.FreeBSD.org/ports/head/UPDATING[UPDATING] file. However, the definitive answer to any question is undoubtedly to read the source code of http://svnweb.FreeBSD.org/ports/head/Mk/bsd.port.mk[bsd.port.mk], and associated files. +It is possible to browse the files in the source repository by using a web interface. Changes that affect the entire port system are now documented in the https://cgit.freebsd.org/ports/tree/CHANGES[CHANGES] file. Changes that affect individual ports are now documented in the https://cgit.FreeBSD.org/ports/tree/UPDATING[UPDATING] file. However, the definitive answer to any question is undoubtedly to read the source code of https://cgit.FreeBSD.org/ports/tree/Mk/bsd.port.mk[bsd.port.mk], and associated files. [[ports-mailing-list]] == The FreeBSD Ports Mailing List diff --git a/documentation/content/en/books/porters-handbook/makefiles/chapter.adoc b/documentation/content/en/books/porters-handbook/makefiles/chapter.adoc --- a/documentation/content/en/books/porters-handbook/makefiles/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/makefiles/chapter.adoc @@ -1149,7 +1149,7 @@ MASTER_SITE_SUBDIR= make .... -These values and variables are defined in https://svnweb.freebsd.org/ports/head/Mk/bsd.sites.mk?view=markup[Mk/bsd.sites.mk]. New entries are added often, so make sure to check the latest version of this file before submitting a port. +These values and variables are defined in https://cgit.freebsd.org/ports/tree/Mk/bsd.sites.mk[Mk/bsd.sites.mk]. New entries are added often, so make sure to check the latest version of this file before submitting a port. [TIP] ==== diff --git a/documentation/content/en/books/porters-handbook/order/chapter.adoc b/documentation/content/en/books/porters-handbook/order/chapter.adoc --- a/documentation/content/en/books/porters-handbook/order/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/order/chapter.adoc @@ -31,20 +31,6 @@ The first sections of the [.filename]#Makefile# must always come in the same order. This standard makes it so everyone can easily read any port without having to search for variables in a random order. -The first line of a [.filename]#Makefile# is always a comment containing the Subversion version control ID, followed by an empty line. In new ports, it looks like this: - -[.programlisting] -.... -# $FreeBSD$ -.... - -In existing ports, Subversion has expanded it to look like this: - -[.programlisting] -.... -# $FreeBSD: head/ports-mgmt/pkg/Makefile 437007 2017-03-26 21:25:47Z bapt $ -.... - [NOTE] ==== The sections and variables described here are mandatory in a ordinary port. In a slave port, many sections and variables can be skipped. diff --git a/documentation/content/en/books/porters-handbook/porting-samplem/chapter.adoc b/documentation/content/en/books/porters-handbook/porting-samplem/chapter.adoc --- a/documentation/content/en/books/porters-handbook/porting-samplem/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/porting-samplem/chapter.adoc @@ -35,11 +35,6 @@ [.programlisting] .... -# $FreeBSD$ -[ ^^^^^^^^^ This will be automatically replaced with RCS ID string by SVN -when it is committed to our repository. If upgrading a port, do not alter -this line back to "$FreeBSD$". SVN deals with it automatically.] - [section to describe the port itself and the master site - PORTNAME and PORTVERSION or the DISTVERSION* variables are always first, followed by CATEGORIES, and then MASTER_SITES, which can be followed diff --git a/documentation/content/en/books/porters-handbook/quick-porting/chapter.adoc b/documentation/content/en/books/porters-handbook/quick-porting/chapter.adoc --- a/documentation/content/en/books/porters-handbook/quick-porting/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/quick-porting/chapter.adoc @@ -57,8 +57,6 @@ [.programlisting] .... -# $FreeBSD$ - PORTNAME= oneko DISTVERSION= 1.1b CATEGORIES= games @@ -70,7 +68,7 @@ .include .... -Try to figure it out. Do not worry about the contents of the `$FreeBSD$` line, it will be filled in automatically by Subversion when the port is imported to our main ports tree. A more detailed example is shown in the <> section. +Try to figure it out. A more detailed example is shown in the <> section. [[porting-desc]] == Writing the Description Files @@ -232,13 +230,12 @@ .Creating a [.filename]#.diff# for a New Port [example] ==== -Add all the files with `svn add`. `cd` to the base of the ports tree so full paths to the changed files are included in the diff, then generate the diff with `svn diff`. For example: +Add all the files with `git add .`, then generate the diff with `git diff`. For example: [source,shell] .... -% svn add . -% cd ../.. -% svn diff games/oneko > oneko.diff +% git add . +% git diff --staged > oneko.diff .... [IMPORTANT] diff --git a/documentation/content/en/books/porters-handbook/slow-porting/chapter.adoc b/documentation/content/en/books/porters-handbook/slow-porting/chapter.adoc --- a/documentation/content/en/books/porters-handbook/slow-porting/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/slow-porting/chapter.adoc @@ -147,8 +147,6 @@ % diff -u -N newfile.orig newfile > patch-pathname-newfile .... -Do not add `$FreeBSD$` RCS strings in patches. When patches are added to the Subversion repository with `svn add`, the `fbsd:nokeywords` property is set to `yes` automatically so keywords in the patch are not modified when committed. The property can be added manually with `svn propset fbsd:nokeywords yes _files..._`. - Using the recurse (`-r`) option to man:diff[1] to generate patches is fine, but please look at the resulting patches to make sure there is no unnecessary junk in there. In particular, diffs between two backup files, [.filename]##Makefile##s when the port uses `Imake` or GNU `configure`, etc., are unnecessary and have to be deleted. If it was necessary to edit [.filename]#configure.in# and run `autoconf` to regenerate `configure`, do not take the diffs of `configure` (it often grows to a few thousand lines!). Instead, define `USES=autoreconf` and take the diffs of [.filename]#configure.in#. [[slow-patch-automatic-replacements]] diff --git a/documentation/content/en/books/porters-handbook/special/chapter.adoc b/documentation/content/en/books/porters-handbook/special/chapter.adoc --- a/documentation/content/en/books/porters-handbook/special/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/special/chapter.adoc @@ -2951,7 +2951,7 @@ As for the choice of building Java ports from source or directly installing them from a binary distribution, there is no defined policy at the time of writing. However, people from the https://www.freebsd.org/java/[FreeBSD Java Project] encourage porters to have their ports built from source whenever it is a trivial task. -All the features that have been presented in this section are implemented in [.filename]#bsd.java.mk#. If the port needs more sophisticated Java support, please first have a look at the http://svnweb.FreeBSD.org/ports/head/Mk/bsd.java.mk?view=log[bsd.java.mk Subversion log] as it usually takes some time to document the latest features. Then, if the needed support that is lacking would be beneficial to many other Java ports, feel free to discuss it on the freebsd-java. +All the features that have been presented in this section are implemented in [.filename]#bsd.java.mk#. If the port needs more sophisticated Java support, please first have a look at the https://cgit.FreeBSD.org/ports/tree/Mk/bsd.java.mk[bsd.java.mk Git log] as it usually takes some time to document the latest features. Then, if the needed support that is lacking would be beneficial to many other Java ports, feel free to discuss it on the freebsd-java. Although there is a `java` category for PRs, it refers to the JDK porting effort from the FreeBSD Java project. Therefore, submit the Java port in the `ports` category as for any other port, unless the issue is related to either a JDK implementation or [.filename]#bsd.java.mk#. diff --git a/documentation/content/en/books/porters-handbook/testing/chapter.adoc b/documentation/content/en/books/porters-handbook/testing/chapter.adoc --- a/documentation/content/en/books/porters-handbook/testing/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/testing/chapter.adoc @@ -203,7 +203,7 @@ [source,shell] .... -# poudriere jail -c -j 11i386 -v stable/11 -a i386 -m svn+https +# poudriere jail -c -j 11i386 -v stable/11 -a i386 -m git+https .... Create `tank/poudriere/jails/11i386`, mount it on [.filename]#/poudriere/jails/11i386#, then check out the tip of the Subversion branch of `FreeBSD-11-STABLE` from `SVN_HOST` in [.filename]#poudriere.conf# into [.filename]#/poudriere/jails/11i386/usr/src#, then complete a `buildworld` and install it into [.filename]#/poudriere/jails/11i386#. @@ -215,7 +215,7 @@ [source,shell] .... -# poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https +# poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m git+https .... ==== @@ -231,7 +231,7 @@ [source,shell] .... -# poudriere jail -c -j 13amd64 -v head -a amd64 -m svn+https +# poudriere jail -c -j 14amd64 -v main -a amd64 -m git+https .... In order to run a `14.0-CURRENT` Poudriere jail you must be running `14.0-CURRENT`. In general, newer kernels can build and run older jails. For instance, a `14.0-CURRENT` kernel can build and run a `11.4-STABLE` Poudriere jail if the `COMPAT_FREEBSD11` kernel option was compiled in (on by default in `14.0-CURRENT`[.filename]#GENERIC# kernel config). @@ -268,7 +268,7 @@ [TIP] ==== -For jails employing a `svn+*` method, it is helpful to add `-J _NumberOfParallelBuildJobs_` to speed up the build by increasing the number of parallel compile jobs used. For example, if the building machine has 6 CPUs, use: +For jails employing a `git+*` method, it is helpful to add `-J _NumberOfParallelBuildJobs_` to speed up the build by increasing the number of parallel compile jobs used. For example, if the building machine has 6 CPUs, use: [source,shell] .... @@ -291,16 +291,16 @@ [source,shell] .... -# poudriere ports -c -m svn+https +# poudriere ports -c -m git+https .... -These commands create `tank/poudriere/ports/default`, mount it on [.filename]#/poudriere/ports/default#, and populate it using either man:portsnap[8] or Subversion. Afterward it is included in the list of known ports trees: +These commands create `tank/poudriere/ports/default`, mount it on [.filename]#/poudriere/ports/default#, and populate it using Git, man:portsnap[8], or Subversion. Afterward it is included in the list of known ports trees: [source,shell] .... # poudriere ports -l PORTSTREE METHOD TIMESTAMP PATH -default svn+https 2020-07-20 04:23:56 /poudriere/ports/default +default git+https 2020-07-20 04:23:56 /poudriere/ports/default .... [NOTE] diff --git a/documentation/content/en/books/porters-handbook/upgrading/chapter.adoc b/documentation/content/en/books/porters-handbook/upgrading/chapter.adoc --- a/documentation/content/en/books/porters-handbook/upgrading/chapter.adoc +++ b/documentation/content/en/books/porters-handbook/upgrading/chapter.adoc @@ -31,7 +31,7 @@ When a port is not the most recent version available from the authors, update the local working copy of [.filename]#/usr/ports#. The port might have already been updated to the new version. -When working with more than a few ports, it will probably be easier to use Subversion to keep the whole ports collection up-to-date, as described in the link:{handbook}#ports-using/[Handbook]. This will have the added benefit of tracking all the port's dependencies. +When working with more than a few ports, it will probably be easier to use Git to keep the whole ports collection up-to-date, as described in the link:{handbook}#ports-using/[Handbook]. This will have the added benefit of tracking all the port's dependencies. The next step is to see if there is an update already pending. To do this, there are two options. There is a searchable interface to the https://bugs.freebsd.org/search/[FreeBSD Problem Report (PR) or bug database]. Select `Ports & Packages` in the `Product` multiple select menu, and enter the name of the port in the `Summary` field. @@ -48,18 +48,18 @@ % diff -u something.orig something > something.diff .... -Otherwise, either use the `svn diff` method (<>) or copy the contents of the port to an entire different directory and use the result of the recursive man:diff[1] output of the new and old ports directories (for example, if the modified port directory is called [.filename]#superedit# and the original is in our tree as [.filename]#superedit.bak#, then save the result of `diff -ruN superedit.bak superedit`). Either unified or context diff is fine, but port committers generally prefer unified diffs. Note the use of the `-N` option-this is the accepted way to force diff to properly deal with the case of new files being added or old files being deleted. Before sending us the diff, please examine the output to make sure all the changes make sense. (In particular, make sure to first clean out the work directories with `make clean`). +Otherwise, either use the `git diff` method (<>) or copy the contents of the port to an entire different directory and use the result of the recursive man:diff[1] output of the new and old ports directories (for example, if the modified port directory is called [.filename]#superedit# and the original is in our tree as [.filename]#superedit.bak#, then save the result of `diff -ruN superedit.bak superedit`). Either unified or context diff is fine, but port committers generally prefer unified diffs. Note the use of the `-N` option-this is the accepted way to force diff to properly deal with the case of new files being added or old files being deleted. Before sending us the diff, please examine the output to make sure all the changes make sense. (In particular, make sure to first clean out the work directories with `make clean`). [NOTE] ==== -If some files have been added, copied, moved, or removed, add this information to the problem report so that the committer picking up the patch will know what man:svn[1] commands to run. +If some files have been added, copied, moved, or removed, add this information to the problem report so that the committer picking up the patch will know what man:git[1] commands to run. ==== To simplify common operations with patch files, use `make makepatch` as described in <>. Other tools exists, like [.filename]#/usr/ports/Tools/scripts/patchtool.py#. Before using it, please read [.filename]#/usr/ports/Tools/scripts/README.patchtool#. If the port is unmaintained, and you are actively using it, please consider volunteering to become its maintainer. FreeBSD has over 4000 ports without maintainers, and this is an area where more volunteers are always needed. (For a detailed description of the responsibilities of maintainers, refer to the section in the link:{developers-handbook}#POLICIES-MAINTAINER[Developer's Handbook].) -To submit the diff, use the https://bugs.freebsd.org/submit/[bug submit form] (product `Ports & Packages`, component `Individual Port(s)`). Always include the category with the port name, followed by colon, and brief descripton of the issue. Examples: `_category/portname_: _add FOO option_`; `_category/portname_: _Update to X.Y_`. Please mention any added or deleted files in the message, as they have to be explicitly specified to man:svn[1] when doing a commit. Do not compress or encode the diff. +To submit the diff, use the https://bugs.freebsd.org/submit/[bug submit form] (product `Ports & Packages`, component `Individual Port(s)`). Always include the category with the port name, followed by colon, and brief descripton of the issue. Examples: `_category/portname_: _add FOO option_`; `_category/portname_: _Update to X.Y_`. Please mention any added or deleted files in the message, as they have to be explicitly specified to man:git[1] when doing a commit. Do not compress or encode the diff. Before submitting the bug, review the link:{problem-reports}#pr-writing/[ Writing the problem report] section in the Problem Reports article. It contains far more information about how to write useful problem reports. @@ -70,76 +70,56 @@ [NOTE] ==== -Please use man:diff[1] or `svn diff` to create updates to existing ports. Other formats include the whole file and make it impossible to see just what has changed. When diffs are not included, the entire update might be ignored. +Please use man:diff[1] or `git diff` to create updates to existing ports. Other formats include the whole file and make it impossible to see just what has changed. When diffs are not included, the entire update might be ignored. ==== Now that all of that is done, read about how to keep up-to-date in <>. -[[svn-diff]] -== Using Subversion to Make Patches +[[git-diff]] +== Using Git to Make Patches -When possible, please submit a man:svn[1] diff. They are easier to handle than diffs between "new and old" directories. It is easier to see what has changed, and to update the diff if something was modified in the Ports Collection since the work on it began, or if the committer asks for something to be fixed. Also, a patch generated with `svn diff` can be easily applied with `svn patch` and will save some time to the committer. +When possible, please submit a man:git[1] diff. They are easier to handle than diffs between "new and old" directories. It is easier to see what has changed, and to update the diff if something was modified in the Ports Collection since the work on it began, or if the committer asks for something to be fixed. Also, a patch generated with `git diff` can be easily applied with `git apply` and will save some time to the committer. [source,shell] .... -% cd ~/my_wrkdir <.> -% svn co https://svn.FreeBSD.org/ports/head/dns/pdnsd <.> -% cd ~/my_wrkdir/pdnsd +% cd ~/my_ports_wrkdir <.> +% git clone https://cgit.FreeBSD.org/ports.git <.> +% cd ~/my_wrkdir/dns/pdnsd .... <.> This can be anywhere, of course. Building ports is not limited to within [.filename]#/usr/ports/#. -<.> https://svn.FreeBSD.org/[svn.FreeBSD.org] is the FreeBSD public Subversion server. See link:{handbook}#svn-mirrors[Subversion mirror sites] for more information. +<.> https://cgit.FreeBSD.org/[cgit.FreeBSD.org] is the FreeBSD public Git server. See link:{handbook}#svn-mirrors[Subversion mirror sites] for more information. -While in the port directory, make any changes that are needed. If adding, copying, moving, or removing a file, use `svn` to track these changes: +While in the port directory, make any changes that are needed. If adding, moving, or removing a file, use `git` to track these changes: [source,shell] .... -% svn add new_file -% svn copy some_file file_copy -% svn move old_name new_name -% svn remove deleted_file +% git add new_file +% git mv old_name new_name +% git rm deleted_file .... Make sure to check the port using the checklist in <> and <>. [source,shell] .... -% svn status -% svn update <.> +% git status --short +% git pull --rebase <.> .... -<.> This will attempt to merge the differences between the patch and current repository version. Watch the output carefully. The letter in front of each file name indicates what was done with it. See <> for a complete list. - -[[table-svn-up]] -.Subversion Update File Prefixes -[cols="10%,90%", frame="none"] -|=== -|U -|The file was updated without problems. - -|G -|The file was updated without problems (only 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. -|=== - -If `C` is displayed as a result of `svn update`, it means something changed in the Subversion repository and man:svn[1] was not able to merge the local changes with those from the repository. It is always a good idea to inspect the changes anyway, since man:svn[1] does not know anything about the structure of a port, so it might (and probably will) merge things that do not make sense. +<.> This will attempt to merge the differences between the patch and current repository version. Watch the output carefully. The letter in front of each file name indicates what was done with it. The last step is to make a unified man:diff[1] of the changes: [source,shell] .... -% svn diff > ../`make -VPKGNAME`.diff +% git diff . > ../`make -VPKGNAME`.diff .... [NOTE] ==== -If files have been added, copied, moved, or removed, include the man:svn[1] `add`, `copy`, `move`, and `remove` commands that were used. `svn move` or `svn copy` must be run before the patch can be applied. `svn add` or `svn remove` must be run after the patch is applied. +If files have been added, moved, or removed, include the man:git[1] `add`, `mv`, and `rm` commands that were used. `git mv` must be run before the patch can be applied. `git add` or `git rm` must be run after the patch is applied. ==== Send the patch following the link:{problem-reports}#pr-writing/[problem report submission guidelines].