Filesystem Schema Change Notice

["C. Michael Pilato" <cm...@collab.net>]

Yep.  Try as I might, I'm not wise enough to have foreseen the
problems that could arise in a repository given ample copy-related
craziness.  As a result, we need to track a little more information at
the time filesystem copies are made so that we an use that information
when harvesting history data later.  So, what I'm really saying is:

   * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
   * There will be another FS schema change next week, which will    *
   * require you to dump and load your existing repositories, unless *
   * something completely amazing is discovered that will alleviate  *
   * the need for such a thing.                                      *
   * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

I *highly* recommend that if your repositories tend to take a long
time to dump and load that you get a head-start on this.  My favorite
backup strategy is the use of incremental dumps + post-revprop-change
hook logging, and if you're of like mind, you already have your
repository mostly dumped already.

Sorry about the pain, especially so near to the last schema change.
And thanks for embracing this technology early so that we might find
exactly the kinds of bugs these schema changes aim to fix.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Filesystem Schema Change Notice

["B. W. Fitzpatrick" <fi...@red-bean.com>]

"C. Michael Pilato" <cm...@collab.net> writes:

> I *highly* recommend that if your repositories tend to take a long
> time to dump and load that you get a head-start on this.  My favorite
> backup strategy is the use of incremental dumps + post-revprop-change
> hook logging, and if you're of like mind, you already have your
> repository mostly dumped already.

You'll also likely do better to dump, *then* load as piping from a dump
directly to a load will likely cause your disk to thrash like mad, thus
slowing down the whole process.  Piping through gzip might help too as
it will *dramatically* reduce the size of your dump file.

I was also thinking that gzipping and piping the dumpfile to another box
on your network (provided you've got 100 or 1000BT) might prove to be
faster, but in a test I just did across our 100BT LAN, I saw no
difference in time.

-Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Filesystem Schema Change Notice

["B. W. Fitzpatrick" <fi...@red-bean.com>]

"C. Michael Pilato" <cm...@collab.net> writes:

> I *highly* recommend that if your repositories tend to take a long
> time to dump and load that you get a head-start on this.  My favorite
> backup strategy is the use of incremental dumps + post-revprop-change
> hook logging, and if you're of like mind, you already have your
> repository mostly dumped already.

You'll also likely do better to dump, *then* load as piping from a dump
directly to a load will likely cause your disk to thrash like mad, thus
slowing down the whole process.  Piping through gzip might help too as
it will *dramatically* reduce the size of your dump file.

I was also thinking that gzipping and piping the dumpfile to another box
on your network (provided you've got 100 or 1000BT) might prove to be
faster, but in a test I just did across our 100BT LAN, I saw no
difference in time.

-Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org