[darcs-users] multiple branches within a directory

[Timothy Webster]

On Tue, 12 Oct 2004 17:08:32 +0200
Jan Braun <janbraun at gmx.de> wrote:

> Timothy Webster schrob:
> > I like the simplicity of darcs, so much so I want to use it to store system config files,
> > scripts, and other configs.
> > [...]
> > Thoughts is darcs a good choice for this?
> 
> Be warned that darcs has no support for symlinks, the executable bit,
> permissions and similar metadata, which is generally viewed as a large
> obstacle in versioning config files, although you could use a custom
> wrapper script or such as a workaround.
> 
> Symlink support is planned (and should be relatively straightforward)
> for post-1.0, the best semantics for the rest are still worked upon,
> although support for the x bit should be a safe bet as well.
> 
> As far as branching (maintaining differences between individual
> machines) goes, darcs should handle that just fine, as long as you have
> a clear plan about how you'll move patches between your different
> repositories. But as Mark said, we might better judge that if you could
> provide us with a more tangible example of what you want to achieve.

In theory config files and scripts (system admins often mix config data into there scripts)
are grouped as follows.
- universal
- sub group
- individual

I will be using a repository for updates/deployments for each site. These
repositories are mirrored to each other for redundancy. In effect one
the master repository is distributed. 

When system admins need to make emergency/quick fixes, 
I want to be able to track those changes and 
integrate them into the master repository. Or if the change was in fact
corruption or write the changes. In the interest of speed and efficiency
changes should be detected via hash database (such as used by tripwire/aide).
There are 2 classes of hosts; managed and unmanaged. When changes are
discovered on an unmanaged host the changes will not be over written,
but the administrator will want to choose whether to integrate the
changes that occurred. On managed hosts the administrator needs to
choose whether to integrate the changes or create a new branch, 
otherwise when changes are discovered they will be over written.
However record of changes should not be lost.

To keep things simple all hosts on each site will pull initial/updated
configs from its corresponding site repository. Using a tool something
like a modified getupdate http://marc.merlins.org/linux/talks/getupdates/grhat/
which will do darcs get/pull instead of wget tar files. This gives me a way
to implement wrapper functions required to generate db, cdb files, etc from text files.
This brings up the issue the db and cdb are the real config files, but dumps of them
"text" is what needs to be stored in the repository. I envision a darcs config file
defining text to binary mappings 
"text" -> "cdb" cdb -c -m -t file.tmp file.cdb file
"cdb" -> "text" cdb -m -d file.cdb > file
And a way do tell darcs not to put *.cdb files in the repository, but track their
hashes for changes.(see via hash database above)


(some simple constructed examples)
=================================
Some things are enterprise wide standards, such as /etc/default/rcS

Others fall into groups /etc/default/ntpdate, /etc/ntp.conf
In my company we have several cluster major sites. At each major site
there is 2 peered ntp servers and clients of those servers.

All the ntp client configurations are very similar, but need to point to the
correct server site servers. If I make a change to the client ntp.conf I want
to apply the patch each client branch (branch for each site).

The ntp server configurations also share great deal in common with the clients.
So I would a server branch and a sub branch for each server for host specific ip stuff.

Finally some hosts are not at any major site. These are configured similar to ntp servers,
but have no peer relationships.

                           ntp
                                  
                   client          server _______
                  /    \           /     \       \
              site_a   site_b   site_a   site_b  site_none
                                /   \     /   \                   
                              s1    s2   s3   s4

A ntp server dies "s1", so I setup another host to replace it. And need to adjust site_a
server and client configs. 
Following the first principle of system administration, make all changes in one place 
and only once if possible less we forget stuff.

Lets say I discover a fix which only applies to bsd machines. This starts out as
perturbation, but needs to become branch.

-tim.