[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repository recovery and archiving

From: schmolle
Subject: Re: Repository recovery and archiving
Date: Tue, 24 Apr 2001 20:42:53 +0000

Hi Jesus, list,

>In short, I need the transaction capabilities of a database

I got that impression. Since you are considering Oracle vs CVS, I take it cost 
is not a great consideration? :)

How about this for a rough idea (other people can pitch in if they like):

1. Find a way to capture all the transactions that actually modify anything (I 
hope you are not interested in effectively read-only operations). Some ways (of 
the top of my head; not all of this might work):
  a) Crank up the logging and periodically parse logs and compare to what you 
have processed before.
  b) commitinfo or another method that will trigger upon modifications and 
record vital info in one way or another.
  c) wrapper scripts around CVS commands (very dependant on your user 
community) that do some verification that their intended effect has been 
achieved and then record the information.

2. Have a second (hidden) repository, that is only maintained by your 
transaction-recording process.

A scenario could be that whatever modification has been noticed/triggered is:
  a) Tested for completion (depending on what you are dealing with; there are 
only so many different things you can do to a repository)
  b) Repeated on the hidden repository. This in itself could be something like 
(adding files, for example):
    I) checkout the module from the appropriate branch or the trunk.
    II) seperately, export the added files.
    III) add those files to the workspace from the hidden repository and 
add+commit them, possibly even providing the same comments.
  c) When this operation is deemed succesfully completed, do an incremental 
backup or just tar the whole lot up. (size of repository being an influential 
factor, off course)

That way you can lock/unlock a clean repository for the purpose of taking 
really clean backups, without having to even bother the production CVS. All 
this does seem quite CPU intensive to me, but then again, if you have the 
resource to run Oracle...

If somebody is desperate enough to actually implement this, it would be nice to 
contribute the solution back to the community; there are many applications to 
be thought off that would really benefit from such a rollback facility.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]