RE: FW: Summary of a IRC conversation in #zynot-infra

> From: Amir Guindehi [mailto:[email protected]]
> Sent: Monday, August 11, 2003 12:02 PM

> Hi,
> 
> Sander Striker wrote:
>  >>>So either the correct ebuilds with their dependencies should be 
> published
>  >>>somewhere on the zynot.org domain with instructions, or, we should give
>  >>>instructions how to build from source...
>  >>
>  >>Those Ebuilds are published on the following website:
>  >>
>  >>https://gentoo.datacore.ch/DCwiki.gentoo/Ebuild.jsp?page=DataCore.EBuilds&portage=dc.gentoo
>  >
>  > Right.  Like I said, we need to publish them on the zynot.org domain.
> 
> No, that's not true and I disagree!
> I will not update two sites with the same information!

[...]
Oh, you do not wish to include your svn ebuild in the zynot tree?

Our entire infrastructure is being build with a lot of paranoia in mind.
Pointing people to outside zynot.org for a required component seems
silly in my mind.

>  >>db-4.0.14,
>  >
>  > For a client not a required dependency.
> 
> For a local repository and for svnadmin you need it. So, you already 
> need it if you want to create a local repository for testing purposes! 
> Right?
> 
>>> diffutils,
>>
>> Not a required dependency.
> 
> Wrong.
> 
> It _is required_ for the ebuild! We patch the buggy Makefiles to comply 
> to our wishes on a GenToo system.

Ahum.  I take issue with the term 'buggy Makefiles'.  If a Makefile is
buggy point it out.  But do not make this claim without so clarification.

FWIW, the mailer.py script does make use of an installed 'diff', so
if you are running your own repository and want to have commit mails
you will need that.  That is, until we replace it with calls to bindings
of the internal diff lib.
 
[...]
>>> texinfo, texi2html),
>>
>> Not a required dependency.
> 
> Wrong.
> 
> It _is required_ for the ebuild! We generate info files for GenToo's 
> documentation system.

For the ebuild, but if I am not mistaken you were stating dependencies
in general.
 
>>>Sander, building sources by hand is bad! ;-))
>>
>>
>> Bad, Good, Ugly, whatever.  I'm just saying that you are not unable
>> to get Subversion to install without an ebuild.
> 
> Agree. But to do it consistently over boxes and time you need an ebuild.

I wasn't disputing that.
 
>  >>I wrote a SVN backup script named svnbackup, which is available from:
>  >>
>  >>https://open.datacore.ch/read-only/svnbackup/trunk/
>  >>
>  >>by svn and does exactly that. It dumps every revision commited to a
>  >>separate bzip2 compressed dump file in a configurable directory
>  >>structure. You can configure multiple repositories and then have
>  >>svnbackup backup all those  repositories in one go.
>  >
>  > Dumping individual revisions is interesting, but a full backup every
>  > period T is fine for the reasonable paranoid.  It could be a bit more
>  > convenient when restoring too.
> 
> I do not agree.
> 
> I think a command like:
> 
>    svnbackup load --rep repname new-repository
> 
> _is far more convenient_ than copying or rsyncing databases while 
> running and then replaying the journals to fix the currupted database.
> 
>> Anyway, for the less paranoid among us, hot-backup does the job.
> 
> Which does the above and which is not a very good solution to the 
> problem in my eyes.  It's a dirty hack which only works because the 
> database keeps a transaction journal...

The 'dirty hack' is the recommended procedure straight from the Berkeley
DB documentation.  And ofcourse the database keeps a transaction journal,
that's the whole point and one of the reasons why Subversion uses it.

>> The less paranoid would be defined as the people who feel comfortable 
>> that Berkeley DB 4.0 is a stable product (which given it's widespread use
>> wouldn't be that odd).
> 
> Doing backup is always a good thing.

I wouldn't recommend otherwise.

> Doing backup of _individal revisions as separate files_ is even better
> because you can choose which revision dumps you want to include when
> recreating the database, even _without_ a svnfilter...

Which you should never have to use...  Altering history is bad.  This
should be a last resort.  That's why it isn't a problem if it takes
a little more work (running svndumpfilter over a dump).

We will probably never agree on this, so please agree to disagree.

Thanks,

Sander