On Sun, Dec 11, 2011 at 7:50 PM, <r...@aarden.us> wrote: > I am specifically looking at the Xen hypervisor but it may have broader > applicability. > > I am in a personal workstation environment using Xen as a hypervisor > managing a half dozen guest operating systems. I am planning on one of > those to be an Apache/SVN server. There will be a variety of > repositories. I am considering how I may implement a repository to > track the versioning of guest images. I would like to keep version > histories of the different guests; experimental perturbations, upgrades, > etc. I like the SVN version graph and I am wondering about how much I > can add notes to clarify the differences. Additionally, update the > notes when in retrospect, more information is needed for historical > entries. > > Since the binaries are large, I will probably need to extend the storage > to a slower, cheaper media for the older versions. I want to keep fast > response for new entries. I am wondering how I might have the best of > both worlds and still be able to pull up a full historical graph.
Do *NOT* attempt to store image binaries. Seriuosly. You're asking for pain, since each image will be profoundly distinct from all the others. If you have to do something like this, arrange to use a backup sytem that backups the *filesystems* to a secondary storage device, and you can compare contents from that. If you feel the need, you can add some wrappers to grab boot loaders and partition indices. But storing the entire disk image is like putting the apple tree in your refrigerator to make sure the apples stay fresh: it's an amazing expenditure in resources. > I plan to use SVN both locally and over the Internet for personal use > only; I am looking for comments/cogestions on setting up for this > service. > > I would really like to hear comments and suggestions on implementing > Apache/SVN on such a hosted service and any about overall system > configuration. I profoundly dislike the Apache/SVN setup, and have said so before. This is partly because it's another layer of access control complexity that is orthogonal to the pre-commit or other built-in access configuration. The other, and more powerful reason, is that Linux and UNIX clients for Subversion store the passwords, by default, as plain-text in a well-known location in your home directory. It's possible to set up more clever password storage schemes, such as Gnome or KDE "wallets", but they remain awkward and difficult to use for unattended behavior such as nightly auto-build systems. So wherever feasible, I use svn+ssh. I've also seen reports that Kerberized access can work well, but that would require even more work to set up and could make a working setup even more difficult to access than users will tolerate.
