[NetBSD Developer Wiki]
- view: text
- select for diffs
Sun Nov 6 01:59:12 2011 UTC
(4 years ago) by jmmv
CVS tags: HEAD
Move existing project definitions from projects/gsoc_2011/ to
The goal for this reorganization is to remove any knowledge of the projects
classification from the file hierarchy: the classification goes into tags,
and projects indexes automatically list projects based on such tags.
Also, the current gsoc_2011 name was wrong anyway, because GSoC 2011 has
already concluded and projects would have had to move to a gsoc_2012 directory
Lastly, yes, "projects/project/*" is slightly redundant. But I want to keep
the project lists from the projects "database" clearly separated.
This is as proposed in www@.
title="Version control config files"
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).
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb