Re: r3205 cvs2svn broken?

On Tue, 2002-09-24 at 16:52, Alex Zepeda wrote:
> On Tue, Sep 24, 2002 at 01:30:36PM -0500, cmpilato@collab.net wrote:
>
> > Does everything still work if the %apply line for const char ** is
> > removed in addition to const char ** being added to the OUTPARAM list?
>
> Well it appears to work, I didn't have time to test it really. But with
> that later line removed I get:
>
> CONFLICTS: '_10071408_p_char'
>
> with it in place, I get:
>
> CONFLICTS: '0x4'
>
> Now if there was an easy fix for the 2-15x size difference in repos
> between cvs and svn, that'd be awesome (cvs2svn of kdelibs -- a roughly
> 180mb repo filled up my disk with nearly 2.8gb of data... oops).
>

Have you been cleaning up the database repository?

***Use this at your own risk.*** Make backups read the docs on Berkeley
DB, sacifice a chicken, whatever makes you feel safe.

If found it highly useful to do this:

 cd /path/to/repos/db/ ; rm `db_archive`

Some things to note:

First off, you should be in the repository directory, there is a db
directory in there. You are in the right directory if you see a file
named DB_CONFIG. The next thing is make sure db_archive is the one for
db4, not db3. I had problems with a RedHat install, because db3 is the
default install, not db4.

Once you get this right, you can just cron it up and run it all the
time. The advanced version is this:

cd /path/to/repos/db/
for LOGFILE in `db_archive` ; do rm $LOGFILE ; done

That will remove the files, and not spit out an error message if there
are none.

If found that files named *.log or is it log.* are taking up most of the
space, and those are archive logs for recovery using the database.
Those can be removed if the data in them has been written to the
datafiles. The utility db_archive is tells you which ones are okay to
delete, and still have full recovery. Go read up on the Berkeley DB
documentation, I'm talking about stuff I don't know a lot about. I'm
guessing its very similar to PostGres and Oracle, which I am familiar
with.

As an alternative you can gzip those files, and save them if you feel
like it. It gives you the ability to replay the database to any point
in time, which is nice from a recovery perspective. I throw anything
older then a couple of weeks aways, just because if I lose more then a
couple of weeks, I'm screwed anyways.

        Thanks,
                Kirby

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

-- 
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org