Building a tool to make the process automated

[Ken Bloom]

On Tuesday 12 June 2007 03:13:06 pm Lois Desplat wrote:
> Hi,
>
> Thanks to Joey Hess and his CVS and SVN articles which allowed me to
> find this mailing list and give me more information. 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. As I wrote my SoC abstract, I wanted
> to use SVN and it seems that is what most of you use. The primary
> backend that I will use will be Bazaar-NG but we can stick with SVN
> now since I will also implement it with SVN.

I'd like to know a little more about Bazaar-NG's suitability for this 
task as compared to Subversion.

> 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).
>
> I found that quite a few applications store information that is not
> necessary to put under revision control (firefox's cache files), do
> you handle that individually or do you usually not care?

I don't version caches. In general, I prefer to assume something is to 
be left unversioned unless I explicitly add it, although with 
appropriate configuration (and I expect this will involve writing a lot 
of policies and having an extensible mechanism for specifying policies) 
I could be open to changing that behavior.

One thing I've noticed is applications whose configurations you'd like 
to keep, but that automatically update metadata whenever you read the 
files, whether you care about it or not. This leads to lots of changes 
that you commit, even though you don't really want to. (Like bookmarks 
files, and other things that I discuss on the wiki). Having ways of 
dealing with this would be nice.

> 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?

Hasn't been a problem for me yet, in fact with my backup script (also on 
the wiki somewhere) I've found that my mail spool grows more quickly 
than my repository.

> 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
> recreated which helps in keeping the versioning history.
>
> 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?

I think a big advantage is to keep the file around in the repository so 
that if I need to find it later, I can. What I do need is a better way 
to search through the repository and restore something when I need it. 
The svn command never seems to do it quite right, and when it does, 
it's not easy. Any ideas?

I suppose the flip side of this is that if you are ever the target of 
litigation or espionage, then you can't plausibly "lose" your old files 
(I'm not sure whether this is allowed or not), but I imagine the people 
developing software in a corporate setting are more concerned about 
this than most home users. It's also possible that if you really are 
concerned than you shouldn't be using version control anyway. (Although 
I'm open to being convinced otherwise about these)

> Thank you very much for the wiki which I am going through right now
> and your articles.
>
> Lois Desplat.
> _______________________________________________
> vcs-home mailing list
> vcs-home at lists.madduck.net
> https://albatross.madduck.net/mailman/listinfo/vcs-home



-- 
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20070612/ff2fe047/attachment.pgp>