.TH RVC-MULTIFILES 1 "Feb 17, 2009" "" .SH NAME rvc-multifiles - Mini-Tutorial on rvc multi-files .SH Background Very often you are in the situation that a configuration file is shared among several machines you are administrating, but a small fraction is specific to that very machine. In these cases it is often desirable to have the joint part under version control jointly, so that changes can easily be distributed among the various machines; however, the specific parts should be kept under version control on a per-machine basis. If the program reading the configuration file in question supports some form of "include" mechanism, this is an easy task. Unfortunately, some programs don't. This is where rvc multifiles come into play. They are a single file on the remote place, but a tracked as concatenation of several individual local files that are kept under version control separately, possibly even in separate repositories, maybe even of separate version control systems. .SH Building Multifiles Multifiles are built by first installing the first part as usual. This part is the main part (usually the part of the file that is shared among various machines) and all permissions are taken from the corresponding rvc-places entry. Afterwards, new files can be appended; here again, their rvc-places entry must specify the correct location. Say, for example, you have in a module sysconf a file ssh_known_hosts with your globally known hosts (machines in the wide world you would like to connect to via ssh) and also have a file ssh_known_hosts in the module local_conf containing hosts only available to that particular machine (e.g., because they are only visible in some local network where this machine resides, but your other machines don't). Both modules contain an rvc-places entry saying that ssh_known_hosts should reside in ~/.ssh/known_hosts. Then you would build your multifile by stating \fBrvc installfile ssh_known_hosts sysconf\fR .br \fBrvc appendfile ssh_known_hosts local_conf\fR .br .SH Maintaining Multifiles As usual with rvc, once files are properly installed, you work with rvc by calling it at the remote place. The commands rvc diff and rvc store apply to all parts of a multifile. So \fBrvc diff ~/.ssh/known_hosts\fR .br would show changes to that file, attributed to the two parts of the file. Here, the remote file is internally split into pieces (see rvc-files(5) for where they are stored) using a heuristic trying to minimise the total amount of changes occurring in the individual parts. Similarly \fBrvc store ~/.ssh/known_hosts\fR .br would, after splitting store the various parts in the involved modules. For each part, the appropriately substituted RVC_STORE_COMMAND would be called, allowing you to give individual commit messages to the various parts (in fact, as the parts belong to potentially different repositories, it is necessary to call the hook individually!). The rvc do command only works on the specified part (using the \-part option). If no part is specified, part 0 (i.e., the first an main part) is assumed. So (assuming RVC_VCS set to cvs) \fBrvc do log ~/.ssh/known_hosts\fR .br would give you the history of the main part of that file and \fBrvc do update ~/.ssh/known_hosts\fR .br would update the shared part of that file without touching the local part (assuming it does not contain any remote changes). To access the local part you would call commands like \fBrvc \-part 1 do log ~/.ssh/known_hosts\fR .br \fBrvc \-part 1 do update ~/.ssh/known_hosts\fR .br .SH SEE ALSO .BR rvc "(1)" .SH AUTHOR Klaus Aehlig