Hi,
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
exists in.
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
there)
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
layer.
You can find more on this topic as well as on my problems in my blog, at
http://blog.drinsama.de/erich/en/linux/
My "prototype" is implemented in python, with pysvn. You can download it
from http://people.debian.org/~erich/laysvn/
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)
best regards,
Erich Schubert
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 14 05:37:42 2005