File:  [NetBSD Developer Wiki] / wikisrc / projects / project / pkgsrc_config_vcs.mdwn
Revision 1.5: download - view: text, annotated - select for diffs
Thu Nov 15 12:07:58 2018 UTC (4 years ago) by leot
Branches: MAIN
CVS tags: HEAD
This project was done during GSoC 2018 by Keivan Motavalli.

(I have not added the `done_by=' tag because it still needs to be reviewed and
imported and added a note about that and removed the `[[!tag gsoc]]' because
despite the review work can be still considered a project it is not suitable for
a GSoC.)

[[!template id=project

title="Version control config files"


[Thomas Klausner](

duration="3 months"

Put config files (etc/) installed by pkgsrc into some version control system to help keeping track of changes and updating them.

The basic setup might look like this:

* There is a repository containing the config files installed by pkgsrc, starting out empty.
* During package installation, pkgsrc imports the package's config files into the repository onto a branch tagged with the name and version of the package (if available, on a vendor branch). (e.g.: digest-20080510)
* After installation, there are two cases:

  1. the package was not installed before: the package's config files get installed into the live configuration directory and committed to the head of the config repository
  2. the package was installed before: a configuration update tool should display changes between the new and the previous original version as well as changes between the previous original and installed config file, for each config file the package uses, and support merging the changes made necessary by the package update into the installed config file. Commit the changes to head when the merge is done.

* Regular automated check-ins of the entire live pkgsrc configuration should be easy to set up, but also manual check-ins of singular files so the local admin can use meaningful commit messages when they change their config, even if they are not experienced users of version control systems

The actual commands to the version control system should be hidden behind an abstraction layer, and the vcs operations should be kept simple, so that other compatibility layers can be written, and eventually the user can pick their vcs of choice (and also a vcs location of choice, in case e.g. the enterprise configuration repository is on a central subversion server).


* choose a VCS system (BSD licensed is a nice-to-have)
* write wrappers around it, or embed its functionality
* demonstrate usage in upgrades


* extend functionality into additional VCS systems

This project was done during Google Summer of Code 2018 by Keivan Motavalli
[Configuration files versioning in pkgsrc](
project. At the moment the code need to be reviewed and imported in pkgsrc.

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb