Re: Subversion vs CVS for document files

On Tue, Nov 14, 2006 at 07:30:02PM -0000, Nikki Locke wrote:
> John Rouillard wrote:
> > If I want to see how many versions of an ldap config file has been
> > released, I have to go to the log messages and look at all the
> > revisions and count them (or use a program to do the same). Where
> > revision 1.6 of the file tells me I have had 6 copies of the file with
> > no requirement to be able to access the repository. If I know that the
> > file is at revision 2010 in svn, does that tell me anything about the
> > number of releases of this file? It does tell me about the repository,
> > but if I only want a file number because it has no relation to the
> > repository as a whole (e.g. a document rev number) then...
>
> Just because you have (CVS style) revision 1.6 of a file, it doesn't mean
> there have only been 6 changes to the file. What about the extra 10 changes
> there might have been in a 1.2.1 branch?
>
> If you promise not to branch, then file revision numbers do tell you a small
> amount of information (which you can get in SVN from the log). But
> as soon as
> you have branches, then a file revision number becomes much less meaningful.

It does imply that this version had 5 ancestors however. Much in the
same way that the 1.2.1.6 file has 7 ancestors (1.1, 1.2,
1.2.1.1 ... 1.2.1.5).

> > In my case I have to cherry pick files at different revisions into a
> > single tag all the time because the files are loosely coupled but
> > deployed as a single entity (system configuration) but I currently
> > have 40 or so subsets of files that are totally independent. So I get
> > revision 1026 of the ssh keys files, revision 223 of the ssh config
> > files, revision 2230 of the ldap config files etc.
>
> No wonder you are having trouble coping :-)
>
> I'd be interested to know how this comes about - mainly so I can avoid
> getting myself into the same situation!

I use Config <http://www.cs.umb.edu/~rouilj#Config> for maintaining
systems. When it was first developed CVS was used for the underlying
versioning system.

The primary model of working with the system is to have all work done
on the trunk and have a series of test systems that get the current
config from the trunk. Because this is a repository of software
configuration files:

   * daemon configurations (/etc/sshd/sshd_config)
   * /etc/hosts files
   * lists of what programs should be running on a system (think
     /etc/rc setup)
   * iptables firewall rules
   * sets of files to deploy LDAP in our domain
   * files that control the deployment of the config files
   * ...

that are distributed by other mechanisms, it forms a configuration for
all the systems maintained through Config. So if something blows up,
you can back track the config to an earlier known state and reapply a
stable configuration for all the machines on the network.

Since there is very loose coupling (or no coupling) between many sets
of files. E.G. the list of sshd known_hosts has no impact on the
filesystem mount points, the file subsets can be tested in isolation
and promoted to production.

Now for production use, the tested file subset is what needs to get
deployed. So under SVN I have to pull the set of tested files (by name
and version as they may be a newer untested version of known_hosts for
example) into the production tree and push the changes to the
production hosts from the production tree of the repository. So the
production tree is composed of tested subsets of files that are
migrated from the trunk.

In CVS you simply moved the per file tag PRODUCTION from one version
to another version in the tree (leaving an old tag in place
PROD_YYYYMMDD to mark the prior production release in case you needed
to revert). A 'cvs update' of the work area that was distributed to
all the hosts on the network from the PRODUCTION sticky tag gets the
new versions of the files. It is a very simple selection method from
the (single trunk) tree in cvs.

There is no simple way in SVN to select files in a repository that are
at different versions without copying each and every file to a new
name in a new tree. But that is exactly what you need in a system
administration (or document management system). SVN isn't really able
to do this as efficiently (with respect to user effort and reduced
likelyhood of mistakes) as CVS. however the ability to move
directories around and change the structure of the repository with
ease is a win and why I changed to SVN in the first place.

So to prevent the problem I have make sure you only work on
repositories with tightly coupled files (e.g a piece of software) and
stay away from administering large installations of systems.

--
				-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org