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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5312350622318136==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig7D4689D8D39DBFC88F09DA9B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7D4689D8D39DBFC88F09DA9B
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Sander Striker wrote:
>>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.

Yes. _When_ we have a published base Zynot distribution we can adapt the 
ebuilds to Zynot's way of things. But as long as that not yet the case I 
see no cause for the double work.

>>>>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.

Buggy from GenToo's point of view. The Makefile patch contains:

  ### these possibly need further discussion
-swig_pydir = @libdir@/svn-python/libsvn
-swig_pydir_extra = @libdir@/svn-python/svn
+swig_pydir = @libdir@/python2.2/site-packages/libsvn
+swig_pydir_extra = @libdir@/python2.2/site-packages/svn

> 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.

Voila ;-) It's needed, since we install:

DB_TOOLS="blame.py dumpprops.py geturl.py revplist.py svnshell.py 
check-modified.py getfile.py putfile.py svnlook.py"

and

HOCK_SCRIPT="commit-access-control.pl commit-email.pl mailer.py 
propchange-email.pl svnperms.py"

>>>>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.

Sorry. The general way here is Ebuilds... ;-))
Yes, I'm stating the dependencies for the DataCore Subversion Ebuild.

>> >>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.

Recomending something hacky does not mean it's no hack... ;-)

>>>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).

Now, since Subversion's version 0.26.0 is way < 1.0, I would advice to 
have _every_ possible disaster in mind! I for one was very happy about 
the idea, to _be able_ to change history (by excluding a special 
revision) in case a revision gets somehow (i'm going hypothetical here) 
mangled/corrupted...

It's also very good way to do incremental backup, since it creates new 
files only when a new revision gets committed.

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

*evil grin*

/me agrees to disagree

Cheers
- Amir

-- 
Amir Guindehi, [email protected]
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland


--------------enig7D4689D8D39DBFC88F09DA9B
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/N8vBbycOjskSVCwRAnhwAJ0ZV8BeOpuwAw7CfVxUZAypYuQBggCeJzg6
orDTG/2BYCJb8ZTKbJ9rV1o=
=xFB8
-----END PGP SIGNATURE-----

--------------enig7D4689D8D39DBFC88F09DA9B--


--===============5312350622318136==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Zynot-dev mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynot-dev

--===============5312350622318136==--