RE: Subversion backup

> If you're that concerned about loosing one or two commits when you do a
> full
> backup, then you should have a post-commit script that dumps that revision
> that
> was just made onto another filesystem. After all, even with your full
> backups,
> you could loose a days worth of work if the disk fails after the day of
> commits
> but before a full backup. Or what happens if there's a commit at 11:05
> PM,
> you've lost it.

It seems to me that you gain no benefit from locking people out. Look at the two scenarios assuming your repository is at rev 1000.

1. Start backup.
2. rev 1001 - 1005 are committed while the backup is running
3. Backup is done to rev 1000 inclusive
4. The repository is at rev 1005

Or...

1. Lock people out.
2. Start backup
3. Backup is done to rev 1000 inclusive
4. You allow commits again
5. revs 1001 - 1005 are committed
6. The repository is at rev 1005

Aren't the results the same? If you stop people from committing before a backup you won't bu those commits. If you allow people to commit during the backup you won't (or might) get those commits.

BOb

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2081236

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-06 16:26:19 CEST