So if I'm reading this right, if I restore a repo from backup & a
commit had been taking place --
- if the db/current file points to one rev older than what is in
db/revs, then I am fine without modifications, and only have lost one
revision. -- is there a way to _safely_ update db/current
programatically to get that revision back since the data is in
db/revs?
- if the current file points to one rev newer than what is in db/revs
(because of the order of the backup), I can safely point it back one
revision manually. (?)
Are there any plans of adding this type of recovery functionality to
svnadmin recover for FSFS repos? I remember reading sometime ago some
talk of this. Was hoping to avoid a post-commit append to the dump
file like I do now with BDB for perf reasons
(autoversioning/WebDAV/Apache), so long as FSFS provided a way to
safely restore from a hot backup (not a hot copy, but could consider
this if its the only way to guarantee a copy on tape that is safe to
recover.)
Thx,
Kyle
On 5/1/05, Max Bowsher <maxb@ukf.net> wrote:
> Kyle Kline wrote:
> > The docs indicate that FSFS is suited well for backup schemes, with
> > the caveat that if a backup takes place while a commit is in progress,
> > the db/current file may not indicate the true current rev in the
> > db/revs directory.
> >
> > My backup software does not allow me to specify orders of files to
> > avoid this, and I would like to avoid doing a hotcopy due to the size
> > of the repository.
> >
> > If I needed to restore and my db/current file is out of date, Is it as
> > simple as editing the file? I notice there are three values in the
> > file, <current-rev> <unknown -- hash?> <unknown> ......
>
> No, no _absolutely_ not!
>
> I believe (but am not totally certain) that *decreasing* the current rev is
> safe.
> However, *increasing* the current rev is likely to cause severe badness, as
> this will mean that the other two values (next available unique IDs for two
> kinds of objects) would then be too old, and so the same 'unique' id could
> be assigned to multiple objects! Undefined erroneous behaviour would likely
> result.
>
> Max.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 1 16:57:19 2005