I assumed that you would be able to confirm that!
Actually, this approach could be very helpful as I was worried about
having to sort out the python bindings for subversion 1.7 for the
version of python that is used on the VM. If I don't need svnrdump, I
should be able to use the standard distro packages.
I assume that this is of less interest for the allura-dev list so sorry
if this is a bit off topic for you.
Cheers,
Gary
On 08/08/12 23:40, Greg Stein wrote:
Subversion has no problems at all with NFS.
On Aug 8, 2012 6:36 PM, "Gary Martin" <[email protected]
<mailto:[email protected]>> wrote:
Hi everyone,
I should work out how to test this suggestion but I would expect
it to work. I got Bloodhound set up with the postgresql backend so
that aspect should be fine (I seem to remember reading about
problems when using sqlite). After that, I assume that we can work
with everything as read-only from bloodhound's point of view.
So, as long as subversion can also play nicely with NFS then I
have no current reason to suspect problems with this approach at
this point.
Cheers,
Gary
On 08/08/12 22:26, Greg Stein wrote:
Very cool!
But with that said... I was on IRC, and the Infra guys might
actually
create a full repository mirror for us. The thing is that Apache
Allura (also incubating) will want a copy of their project(s),
too.
Tho... I think they're going with Git, but the concept is the
same.
Bloodhound and Allura both need local read-access to repositories.
Infra was thinking about sync'ing repository copies over to a
box (I
forget the name). The BH and Allura VMs would be migrated over
to that
same box. The repositories would then be exposed via NFS, and
the two
VMs would (locally) mount that NFS share.
I believe the Right Answer here is for both projects to
confirm that
this option is workable, and for us to ask Infra to start
setting it
up.
Thoughts?
Cheers,
-g
On Tue, Aug 7, 2012 at 2:29 PM, Gary Martin
<[email protected] <mailto:[email protected]>>
wrote:
Not sure if this could be of interest beyond Bloodhound.
It is a very simple
script (and quite possibly over-complicated in reality).
The attachment referred to is here:
https://issues.apache.org/bloodhound/attachment/ticket/156/emptyrevs.py
Just tested it on 1229640 empty commits:
python3 emptyrevs.py 1229640 | eatmydata svnadmin
--bypass-prop-validation load repos/
which took about 2 hours - I suspect that the svnadmin
load was the real
bottleneck.. it is just a few seconds to create about 92M
of data if you
direct to a file instead.
Cheers,
Gary
On 08/07/2012 06:47 PM, Apache Bloodhound wrote:
#156: Local copy of bloodhound part of Apache repo for
browse
functionality
------------------------+-----------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: critical | Milestone: Release 2
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+-----------------------
Comment (by gjm):
As part of my investigation around creating a
mirror of the bloodhound
portion, I have written a very simple script (only
complicated when I
decided to have a quick look at the argparse module
and python2/3
issues),
inspired by a suggestion from Philip Martin.
I have attached that script
[attachment:emptyrevs.py here]. It may be
worth putting in the bloodhound repository in case
we need it again of
course.
