On Jul 5, 2006, at 13:45, Ulrich Eckhardt wrote:
>> Can anybody tell me what the implications of just doing a normal
>> (unix dump or tar of flat file structure) of an fsfs repo might
>> be? Is it
>> safe, or should I still be using "svnadmin dump"?
> IMHO, yes, because it is The Documented Way(tm) to make backups.
>> I did some testing, and it seemed to me that I could take a repo,
>> rename it,
>> move it, copy it, make a tarball out of it, delete it, then
>> restore it from
>> tarball, and it seemed safe and still functional in every case.
>> But I don't
>> want any nasty surprises, so if anybody knows of a reason this is
>> not a good
>> idea, please let me know.
> The FSFS backend depends on portable ways to access files, so
> stuff is probably not needed (and thus can't fail).
>> I know you can't get away with this with a berkley repo,
> Yes you can, but Subversion used different versions of BDB in the
> backend and
> those versions are not necessarily compatible. Usually they are
> but not necessarily so. That might be the problem that you were
> referring to.
> Assuming the FSFS backend suddenly finds that it also needs something
> different, it might require an update of the existing repository,
> too, so it
> could develop the same problems. That is another reason for me to
> rely on
> dumpfiles (which in fact also come in different versions, but those
> have a
> guaranteed upgrade path built into Subversion).
There's also the way that when you commit to a BDB repository, it has
to modify old revisions, because it stores the complete current file,
and then deltas going back in time. But FSFS only writes a new
revision, as a delta against previous revisions; old revisions never
change in FSFS. Also, in a BDB repo, the BDB files can be changed
merely by reading the repo, whereas with FSFS the repo files will
only change through a commit. All of this makes a plain old file-copy
backup of an FSFS repo much likelier to succeed than such a backup of
a BDB repo.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jul 5 16:09:07 2006