On Wednesday 08 July 2009 01:42:56 Scott Gifford wrote: > Peter Jordan <usernetw...@gmx.info> writes: > > Suno Ano, Wed Jun 17 2009 19:07:31 GMT+0200 (CEST): > >> Peter> Metadata = data stored in .svn/ ? > >> yes, problem is, Subversion does not have one directory i.e. one > >> .svn/ > >> at the root of the project where is stores metadata but it scatters them > >> all over the place which is very annoying. Git only has one .git/ at the > >> project root at that is it > >> http://sunoano.name/ws/public_xhtml/scm.html#why_git --> metadata > > > > svk does not store the metadata in the project path at all > > Being able to use something like etckeeper with svn (maybe via svk) > would be very useful to me, has anybody tried this? > > ----Scott.
I wrote a program a few years ago that uses svn to help keep track of /etc.
The name of the program, unsurprisingly is etcsvn.
I stopped using it around 2007, choosing to use paella to help handle some of
this. I found that keeping track of /etc in its entirety was somewhat
burdensome (this was at a time when packages were placing things in /etc that
shouldn't have been there, such as gconf).
I'm not sure how loosely you are using the phrase "like etckeeper", but I can
give you a short synopsis of similarities and differences.
etckeeper:
uses directories that's easy to add scripts to make it very flexible
(this could be done with etcsvn, with a little bit of work)
hooks into apt to track changes to /etc made by upgrading packages
(I never thought about this when I wrote etcsvn, but it would be a nice
addition)
etcsvn:
/etc is an export, not a working copy (I was concerned about keeping the /
partition small and a working copy is over twice the size).
the working copy is kept in /var/lib/etcsvn (or somewhere under there, I can't
remember now)
the working copy is only readable by root
etcsvn sets a umask of 077 so exports back to /etc can be done securely
etcsvn uses svn properties to keep track of ownership, file permissions, and
mtime (this could be extended to keep track of other metadata, including
extended attributes. I knew nothing about xattr when I wrote this).
since subversion can handle empty directories, etcsvn can do so as well
since subversion can do a checkout of a subdirectory in a repository, you can
keep /etc from multiple machines in the same repository (in these cases the
repository was never accessible from those machines, I used to keep it on my
laptop and use ssh port-forwarding and agent forwarding to access the
repository on those machines)
etcsvn doesn't handle authentication to the repository (I normally used ssh to
handle this)
etcsvn may need some work to use https methods better
etcsvn uses an etcsvn.conf file in its working copy, where you specify the
directories and/or files to be tracked. This means that you can also track
files and/or directories in /var or elsewhere, and keep ownership,
permissions, and mtime straight.
I haven't touched the code in a long time. It may not work as it used to.
After looking at it, the last thing I did was a few weeks ago, when I changed
all the os.system calls to use subprocess instead (something I've been trying
to do across the board with all my python code).
I have been also thinking about using another strategy, instead of keeping all
of /etc in subversion. Basically like this:
get package list through dpkg --get-selections
conffiles = list()
tracked_files = list()
for package in packages:
dpkg --status (get the conffiles and add them to the list)
walk through /etc
check if file is in conffiles list
if file in conffiles:
check md5sum
if md5sum differs:
tracked_files.append(file)
else:
check file in ignored_list
if not in ignored_list:
tracked_files.append(file)
if file in track_anyway_list:
tracked_files.append(file)
add tracked files to svn
This would keep the amount of files that were being tracked down to a minimum.
Anyway, if you are interested in it, look it over, maybe try it out and let me
know. It may be outdated, but bringing it back up to date shouldn't be too
difficult.
--
Thanks:
Joseph Rawson
signature.asc
Description: This is a digitally signed message part.
