It is no longer relevant to the day-to-day operations of the project. It's all
done with git now. We have the old content in the doc repo should someone need
this information in the future.
@ -836,216 +836,6 @@ If something looks fishy, ask for help.
Make sure to commit a top level directory to have the mergeinfo included as well. Do not specify individual files on the command line. For more information about committing files in general, see the relevant section of this primer.
[[svn-advanced-use-vendor-imports]]
==== Vendor Imports with SVN
[IMPORTANT]
====
Please read this entire section before starting a vendor import.
====
[NOTE]
====
Patches to vendor code fall into two categories:
* Vendor patches: these are patches that have been issued by the vendor, or that have been extracted from the vendor's version control system, which address issues which cannot wait until the next vendor release.
* FreeBSD patches: these are patches that modify the vendor code to address FreeBSD-specific issues.
The nature of a patch dictates where it should be committed:
* Vendor patches must be committed to the vendor branch, and merged from there to head. If the patch addresses an issue in a new release that is currently being imported, it _must not_ be committed along with the new release: the release must be imported and tagged first, then the patch can be applied and committed. There is no need to re-tag the vendor sources after committing the patch.
* FreeBSD patches are committed directly to head.
====
===== Preparing the Tree
If importing for the first time after the switch to Subversion, flattening and cleaning up the vendor tree is necessary, as well as bootstrapping the merge history in the main tree.
====== Flattening
During the conversion from `CVS` to Subversion, vendor branches were imported with the same layout as the main tree. This means that the `pf` vendor sources ended up in [.filename]#vendor/pf/dist/contrib/pf#. The vendor source is best directly in [.filename]#vendor/pf/dist#.
To flatten the `pf` tree:
[source,shell]
....
% cd vendor/pf/dist/contrib/pf
% svn mv $(svn list) ../..
% cd ../..
% svn rm contrib
% svn propdel -R svn:mergeinfo .
% svn commit
....
The `propdel` bit is necessary because starting with 1.5, Subversion will automatically add `svn:mergeinfo` to any directory that is copied or moved. In this case, as nothing is being merged from the deleted tree, they just get in the way.
Tags may be flattened as well (3, 4, 3.5 etc.); the procedure is exactly the same, only changing `dist` to `3.5` or similar, and putting the `svn commit` off until the end of the process.
====== Cleaning Up
The `dist` tree can be cleaned up as necessary. Disabling keyword expansion is recommended, as it makes no sense on unmodified vendor code and in some cases it can even be harmful. OpenSSH, for example, includes two files that originated with FreeBSD and still contain the original version tags. To do this:
[source,shell]
....
% svn propdel svn:keywords -R .
% svn commit
....
====== Bootstrapping Merge History
If importing for the first time after the switch to Subversion, bootstrap `svn:mergeinfo` on the target directory in the main tree to the revision that corresponds to the last related change to the vendor tree, prior to importing new sources:
With two commits-one for the import itself and one for the tag-this step can optionally be repeated for every upstream release between the last import and the current import.
====== Preparing the Vendor Sources
Subversion is able to store a full distribution in the vendor tree. So, import everything, but merge only what is required.
A `svn add` is required to add any files that were added since the last vendor import, and `svn rm` is required to remove any that were removed since. Preparing sorted lists of the contents of the vendor tree and of the sources that are about to be imported is recommended, to facilitate the process.
[source,shell]
....
% cd vendor/pf/dist
% svn list -R | grep -v '/$' | sort >../old
% cd ../pf-4.3
% find . -type f | cut -c 3- | sort >../new
....
With these two files, `comm -23 ../old ../new` will list removed files (files only in [.filename]#old#), while `comm -13 ../old ../new` will list added files only in [.filename]#new#.
====== Importing into the Vendor Tree
Now, the sources must be copied into [.filename]#dist# and the `svn add` and `svn rm` commands are used as needed:
[source,shell]
....
% cd vendor/pf/pf-4.3
% tar cf - . | tar xf - -C ../dist
% cd ../dist
% comm -23 ../old ../new | xargs svn rm
% comm -13 ../old ../new | xargs svn add --parents
....
If any directories were removed, they will have to be ``svn rm``-ed manually. Nothing will break if they are not, but they will remain in the tree.
Check properties on any new files. All text files should have `svn:eol-style` set to `native`. All binary files should have `svn:mime-type` set to `application/octet-stream` unless there is a more appropriate media type. Executable files should have `svn:executable` set to `*`. No other properties should exist on any file in the tree.
Committing is now possible. However, it is good practice to make sure that everything is okay by using the `svn stat` and `svn diff` commands.
====== Tagging
Once committed, vendor releases are tagged for future reference. The best and quickest way to do this is directly in the repository:
The `--accept=postpone` tells Subversion not to complain about merge conflicts as they will be handled manually.
[TIP]
====
The `cvs2svn` changeover occurred on June 3, 2008. When performing vendor merges for packages which were already present and converted by the `cvs2svn` process, the command used to merge [.filename]#/vendor/package_name/dist# to [.filename]#/head/package_location# (for example, [.filename]#head/contrib/sendmail#) must use `-c _REV_` to indicate the revision to merge from the [.filename]#/vendor# tree. For example:
If using the Zsh shell, the `^` must be escaped with `\` or quoted.
====
It is necessary to resolve any merge conflicts.
Make sure that any files that were added or removed in the vendor tree have been properly added or removed in the main tree. To check diffs against the vendor branch:
The `--no-diff-deleted` tells Subversion not to complain about files that are in the vendor tree but not in the main tree. Things that would have previously been removed before the vendor import, like the vendor's makefiles and configure scripts.
Using CVS, once a file was off the vendor branch, it was not able to be put back. With Subversion, there is no concept of on or off the vendor branch. If a file that previously had local modifications, to make it not show up in diffs in the vendor tree, all that has to be done is remove any left-over cruft like FreeBSD version tags, which is much easier.
If any changes are required for the world to build with the new sources, make them now, and keep testing until everything builds and runs perfectly.
===== Committing the Vendor Import
Committing is now possible! Everything must be committed in one go. If done properly, the tree will move from a consistent state with old code, to a consistent state with new code.
===== From Scratch
====== Importing into the Vendor Tree
This section is an example of importing and tagging byacc into [.filename]#head#.
First, prepare the directory in [.filename]#vendor#:
[source,shell]
....
% svn co --depth immediates $FSVN/vendor
% cd vendor
% svn mkdir byacc
% svn mkdir byacc/dist
....
Now, import the sources into the [.filename]#dist# directory. Once the files are in place, `svn add` the new ones, then `svn commit` and tag the imported version. To save time and bandwidth, direct remote committing and tagging is possible:
Warner Losh
3 years ago