I've been working on a small python script to create a feature
subversion is currently missing for me: layers.
I want to store the configuration of some server in subversion. There
are files I want to keep in sync on all servers (e.g. /etc/resolv.conf),
and there are files which will never be the same on any two severs
(e.g. /etc/hosts) - and anything inbetween. Merging would probably
become a constant pain here, I guess...
So I wrote a simple layer-based approach. They are simply stacked on top
of each other; the file from the upmost layer is the one I work with.
When I change a file, it should be commited to the first layer the file
New files can either be placed in a configurable default layer, or
require manual user specification (right now commit is not implemented
anyway; you can only sync, then cd to your real checkouts and commit
One special rule: if a file is ignored in a certain layer, all layers
below are "hidden". So I can remove files by ignoring them in a higher
You can find more on this topic as well as on my problems in my blog, at
My "prototype" is implemented in python, with pysvn. You can download it
The biggest issue I had (apart from wishing the pySVN would give me
singleStatus, so I don't need to handle the list) is that I did not find
a way to reliably
query subversion if a (non-existant) file would be ignored. Maybe I'm
missing something though.
Anyway, I've recieved some positive feedback on this layered approach,
maybe this is a feature you could add to the regular subversion client.
This could also solve problems (or at least provide a nice workaround)
people are having with svn:externals - that the URL is stored in the
main svn repository, although multiple checkouts might need different
URLs to access it.
A good extension of my current laysvn configuration would be to allow
layers to apply to arbitrary subdirectories, right now all have to start
at the top level.
Also maybe re-using svn:ignore as described above is not the best thing.
In the case of a default commit layer you might want to have the commit
go through to the next layer in that case e.g. - maybe using a new
laysvn:shadow property would have been better. In my case, reusing
svn:ignore was very well suited)
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
There are only 10 types of people in the world: //\
Those who understand binary and those who don't V_/_
Jemanden zu lieben heißt glücklich zu sein, ihn glücklich zu sehen.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Sep 14 05:37:42 2005