> From: C. Michael Pilato [mailto:cmpil...@collab.net]
>
> Sadly, the book offers hope where today there is very little. See
> http://subversion.tigris.org/issues/show_bug.cgi?id=3457, which I composed
> well after writing the aforementioned book section. :-(
Thank you for this info.
Just a sug
I have a master server, and a slave server configured with pass-thru proxy.
Off the top of my head, I believe they're both 1.6.12, but I'll double check
if that is an important detail.
A user at the slave site does "get lock" on a file. She gets the lock
successfully.
She makes a change, trie
No clues?
> -Original Message-
> From: Edward Ned Harvey [mailto:s...@nedharvey.com]
> Sent: Saturday, October 16, 2010 8:19 AM
> To: dev@subversion.apache.org
> Subject: checksum error
>
> I have a master & slave server, in US and India. They are both 1.6.
I have a master & slave server, in US and India. They are both 1.6.12, but
the slave was 1.5.7 until a few days ago.
The mast is at rev 5050, but the slave will only sync up to rev 5045. Every
time it tries to sync 5046, I get a checksum error in the apache error_log.
It says some file fails
> From: Edward Ned Harvey [mailto:s...@nedharvey.com]
>
> I may take exception:
> http://subversion.apache.org/docs/release-notes/1.6.html
> says "There is no need to dump and reload your repositories. Subversion
> 1.6
> can read repositories created by earlier versio
> From: Edward Ned Harvey [mailto:s...@nedharvey.com]
>
> I'll repost with more specifics once I have them, but for now, I'm just
> asking for advice on how to get better specifics.
Well, I do have one important new development.
Background info:
In production, where
> From: Branko Čibej [mailto:br...@xbc.nu]
>
> On 02.07.2010 14:14, Daniel Shahaf wrote:
> > Edward Ned Harvey wrote on Fri, 2 Jul 2010 at 07:42 -0400:
> >
> >> We first experienced the problem in production. Clients connecting
> via
> >> svn:// to svn
> From: Branko Čibej [mailto:br...@xbc.nu]
>
> On 02.07.2010 13:39, Mark Phippard wrote:
> > There is a common problem people have where they get weird
> performance
> > spikes like this. It is caused by the server not having enough
> > entropy and some code on the server that generates a random
Long story short, I tried like hell to get the profiler to work, and didn't
succeed. I absolutely verified the -pg option was on both the compile and
the link, by reading through the output of "make." Still, the results I got
were as previously posted: basically all zeros. I did check ldd, to e
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
>
> You have done something wrong, very little data has been recorded.
> It's possible you didn't rebuild the libraries, or you are picking up
> the wrong libraries at runtime.
>
> On Linux I would use oprofile rather than gprof.
Bummer.
> From: Edward Ned Harvey [mailto:s...@nedharvey.com]
>
> commit which takes 15 minutes and should take 11 mins.
type-o. Sorry 'bout that.
The problem is a commit which takes 15 mins, and should take 11 *sec*
This time, repeating the problem with profiling enabled, it only took
> From: Stefan Sperling [mailto:s...@elego.de]
>
> Yes. Re-compile all of svn with -pg in CFLAGS. Something like:
>
> env CFLAGS="-O0 -g -pg" ./configure --enable-maintainer-mode \
> --prefix=/usr/local/svn/
> make && make install
>
> Then use a profiler such as gprof t
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>
> By hand!? I thought they had a rule in Programming School against
> doing
> repetitive tasks by hand like that. :-)
Believe me, I spent every minute of that time, imagining how complex my
python script would be, and how to handle the ex
I'll repost with more specifics once I have them, but for now, I'm just asking
for advice on how to get better specifics.
There is some sort of problem, where sometimes, a commit or other operation
which should take ~10sec instead requires ~15min. It is reproducible, but it
depends on the data
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>
> > I've had the greatest complaints for >15min commits.
> >
>
> So, a commit takes 1min when the server is idle, and 15min when the
> server is busy.
Actually, I'm surprised what I'm learning now. Although it matters if the
serv
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>
> Edward Ned Harvey wrote on Tue, 29 Jun 2010 at 07:15 -:
> > Svnserve is using standard zlib (not a parallel implementation) so
>
> You can disable all (most?) compression by not advertising the
> svndiff
Compression can be good, or bad for performance. Whenever somebody has
large binary files managed by svn, and all the access is on a high speed
LAN, then compression is usually bad ... I'm trying to help a company right
now, where that is the situation. Performance is *crazy* bad because we're
w
17 matches
Mail list logo
