"marc gonzalez-carnicer" <carnicer.lists@gmail.com> wrote on 01/25/2007
09:54:38 AM:
> hi,
>
> my company is seriously considering adopting svn as
> their "official" VCS. i guess i may have to do some
> repository administration, or at least provide a
> framework where the sysadmins can take care of
> backups, etc (i am not a sysadmin myself, i am a
> developer, and have used svn for 2+ years).
I've found that there are two types of activities, one-time ("you
never know when it will happen") activities, and recurring (scheduled)
activities, that Subversion administrators will have to deal with.
There are three recurring activities that I can think of. The
first recurring activity is generating weekly full backups of
repositories. This is easily done with the `svnadmin hotcopy` command,
which you could create as a regular cron job. I don't do this right now,
but I will soon, and it will probably be done by a cron-triggered Perl
script.
The second recurring activity might not be worth doing, but for
now I think it is: Every week, run `svnadmin verify` on your
repositories. Hopefully everything will always come back clean, but for
the times when it does not, I'd rather find out this way, as opposed to
having a user come calling with a weird problem. This could also be done
by cron-triggered Perl script, searching the svnadmin output for
unexpected messages, and emailing people when something unexpected is
found.
The third recurring activity is a requirement for certain types of
companies, and in any event is still a good idea: Every three months,
pick a repository, and restore a copy of the repository from backup (if
you have different types of backup, do this once for each type). Once you
have a restored copy, compare it to the existing copy to see if everything
looks the same. This is to make sure that the backups you've taken are
still good. At least some of this will have to be done manually.
Now, for the one-time activities. In the one-time activities,
there are two types: Automated and manual. Although there can be many
types of automatied one-time activities, right now I can only think of two
manual one-time activities.
The first manual one-time activity is giving a new user access to
a repository. In my case, repository access is authenticated off of an
existing Active Directory infrastructure, so it's no big deal. The second
manual one-time activity is creating a new repository; integrating it into
your system of backups, control, and notifications.
Now, there are many automated one-time activities that you could
be doing, all of which are triggered whenever someone writes to a
repository (this includes getting/releasing locks, making a revprop
change, and committing). Possible activities include sending emails,
triggering ViewVC updates, etc.. Out of all of these, the one that you
must have is running a backup. In this case, I'm not talking about making
a complete copy of the repository whenever someone makes a change: I'm
talking about taking an incremental dump of the revision that has been
created/changed. This will give you one dump file per revision, which you
can backup as an alternative to your full repository copies.
> i have been looking for a detailed task list that a
> svn admin should perform. the svn book does
> provide a reference / user guide, but not a howto
> nor a list of things to do for non-sysadmins.
If you ever find one, let me know!
> i guess i'll have to do some svnadmin dump's,
> hotcopy's and so. but i don't want to invest too
> much time investigating the best practice methods.
I don't know if there are any best practice methods. It all seems
to come down to "If you have the space, take as many backups as you can!"
> in particular, i guess i should provide scripts for
> daily incremental backups, and weekly whole
> backups, both at night. the last one is easy, but
> the first?
You could have your post-commit and post-revprop-change scripts
take an incremental backup, but I wouldn't suggest doing it that way; you
don't want to make your users wait for the backup to take place. In my
case, I simply write a new row to a database, recording the repository
path and the revision number. Eventually a daemon will come along, run
the backup, and update the row to show when the backup was run, and if the
backup script returned any errors.
Later!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 29 09:25:14 2007