Building a tool to make the process automated

Martin Fick mogulguy at
Wed Jun 13 00:09:40 CEST 2007

--- Lois Desplat <lois.desplat at> wrote:

> I am a student in the Google Summer of Code and I am

> making a program that allows to put $HOME and /etc
> under revision control automatically and provides
> tools to easily administer them. 

Cool, was your project one of the ones mentioned on

> My first question is, do you have any general
> advice? I have gone through
> Joey Hess' articles and Scott Scriven's article as
> well as put my own $HOME
> and /etc directories under a VCS (Bazaar-NG).

If you are going to version things like /etc, make
sure that you use a tool that does permissions
versioning.  For much of the files in that dir the
permissions are as important as their content!

It is good to not only be able to ingore files (such
as with svnignore), but to have files that aren't
ignored but are not checked in automatically!  In
other words design your tool so that some
subdirectories/files are versioned but not
automatically checked in, this is particularly
important with externals.

Take externals into consideration since someone might
be building up a directory view pointing to multiple

> Under SVN, how do you make sure that the repository
> does not grow too large over the years? I would 
> assume that after a few years, you might want to
> just keep a monthly granularity of your backups so
> as to reduce the size of the repository?

svnadmin will allow you to prune your repo.

> Some things that I am going to do, my application
> involves a daemon that listens to file movements in 
> the HOME directory. This way a user can just
> move files normally and the daemon records the file
> movement. When it is ready to auto-commit, it can do

> bzr mv (in Bazaar, the move operation is a
> first class operation) or at least let bzr know that
> the file moved instead of being deleted and
> which helps in keeping the versioning history.

That sounds nice!  You might also want to consider
using checksums to identify like files like git does. 
Also look at the vserver project's vhashify tool for
ideas about finding matching files.

> I do not know how to handle deletion though. When
> you delete a file, is it possible to delete all its
> version information too. I know it is very hard
> to not possible to do in Bazaar, how about in SVN?

Again, svnadmin will allow you to do this, but as Eric
mentioned, I would certainly not want this to be
automatic, after all it seems like that would mostly
defeat the purpose of this tool.

> Thank you very much for the wiki which I am going
> through right now and your articles.

Be sure to check out the article about checking in
things automatically:

I actually create this proposed script and have been
using it for a few weeks now.  It is a subset of the
proposed features since I wanted to experiment with it
first.  It is nice being able to specify that you want
a directory to be auto versioned within the directory
itself!  If you want the script, I can send it to you.
 I will make an effort to update that proposal and
attach the script soon.

Lastly, I have a conceptual enhancement for the
svnauto tool that I have been thinking about for a
while, maybe something that you want to consider for
your project also.  The problem: I have directories
that I do not want autoversioned, say a source code
directory for which I want each commit to be a manual
commit with a normal developer's commit message.  But
within these directories I still want the safety of an
autoversioning system!

The solutions I can think of involve copying the
unversioned (or changed but not checked in files) to a
hidden subdirectory which can then be autoversioned
into a separate junk repository.  I don't care if the
junk repository fills up, the goal is to prune it
often.  If later a file that was unversioned in the
primary repository gets added to the primary repo, it
will get deleted from the junk repo, (potentially this
would be a good time to actually prune it from the
junk repo?)  When I get more time to think about this
idea I will add a proposal to the wiki.

Good luck!


Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links.

More information about the vcs-home mailing list