On Mon, 08 Jul 2013 18:06:45 +, Naumenko, Roman wrote:
...
> For example, on one of the other servers it takes 12-13 min to checkout
> repo with ~17000 files, total size 1.2G (with average speed 2MB/s).
>
> Is it considered good, bad or total disaster in term of svn performance?
To me this l
On Mon, 08 Jul 2013 14:33:03 +, Andy Levy wrote:
> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>
> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).
9550 Files, half a GB wc size, 15 seconds.
You may want to use another file system?
Howdy.
I was attempting to use TortoiseSVN to view the differences made in the
history of a specific file, when I received the following exception:
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to rep
Hi Stefan
On Mon, Jul 08, 2013 at 11:18:15PM +0200, Stefan Sperling wrote:
> This patch is sufficient to make it work in my testing.
> Can you confirm?
I can. Thanks a lot!
I downloaded the source of 1.8.0 and compiled that (Debian Wheezy plus a
new copy of serf because I wanted to test using ht
Branko Čibej wandisco.com> writes:
>
> I suggest you add your example to the existing issue:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1537
>
Just did that, that's exactly the kind of response I was expecting. :)
>
> I just increased its priority.
>
Many thanks! I think ma
So I tried it today and it turns out that everything works perfectly. The
mistake I did was that the first time I did 'svn up --ignore-externals
user' and I forgot about the --ignore-externals parameter so the next time
('svn up' in 'software') naturally the externals (for 'user') were fetched
as w
On Sun, Jul 07, 2013 at 01:39:33PM -0500, Frank Loeffler wrote:
> On Sun, Jul 07, 2013 at 06:34:09PM +0200, Stefan Sperling wrote:
> > By design, there are many cases where the working copy code ends up
> > searching the directory hierarchy upwards for a wc.db database in
> > a .svn directory.
>
>
On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
That box has more than enough CPUs (forty), cores are barely utilized.
How is the access over ssh can be configured? I thought it's only
http(s) or svn proto.
http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls
http:/
On Mon, Jul 8, 2013 at 2:40 PM, Naumenko, Roman
wrote:
> On 2013/07/08 2:33 PM, Andy Levy wrote:
>> On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
>> wrote:
>>> On 2013/07/08 12:51 PM, Andy Levy wrote:
On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
wrote:
> Hello,
>
> Ho
On 2013/07/08 2:33 PM, Andy Levy wrote:
> On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
> wrote:
>> On 2013/07/08 12:51 PM, Andy Levy wrote:
>>> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>>> wrote:
Hello,
How fast would you expect svn checkout to be from a server like one
On Mon, Jul 8, 2013 at 1:06 PM, Naumenko, Roman
wrote:
> >
> There are certainly a lot of variables. I'm just trying to find out some
> baseline.
>
> For example, on one of the other servers it takes 12-13 min to checkout
> repo with ~17000 files, total size 1.2G (with average speed 2MB/s).
>
> Is
On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
wrote:
> On 2013/07/08 12:51 PM, Andy Levy wrote:
>> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>> wrote:
>>> Hello,
>>>
>>> How fast would you expect svn checkout to be from a server like one below?
>>> Considering eveyrthing on the server f
On Mon, Jul 8, 2013 at 2:18 PM, Naumenko, Roman
wrote:
> On 2013/07/08 2:06 PM, Thomas Harold wrote:
>> On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
>>> Hello,
>>>
>>> How fast would you expect svn checkout to be from a server like one
>>> below? Considering eveyrthing on the server functioning as
On 2013/07/08 2:06 PM, Thomas Harold wrote:
> On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
>> Hello,
>>
>> How fast would you expect svn checkout to be from a server like one
>> below? Considering eveyrthing on the server functioning as expected.
>>
> Our bottleneck is usually the CPU, but we're do
On 2013/07/08 12:51 PM, Andy Levy wrote:
> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
> wrote:
>> Hello,
>>
>> How fast would you expect svn checkout to be from a server like one below?
>> Considering eveyrthing on the server functioning as expected.
>>
>> Apache 2.2.3
>>
>> 128G mem
>> 10
On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
Hello,
How fast would you expect svn checkout to be from a server like one
below? Considering eveyrthing on the server functioning as expected.
Our bottleneck is usually the CPU, but we're doing svn+ssh access. So I
lean towards a few less but mo
On 08.07.2013 13:47, ВарфоломеевИгорь wrote:
> Branko Čibej wandisco.com> writes:
>
>> I did explain it was a design bug in Subversion on Windows that has been
>> around more or less forever. What other kind of response did you expect?
>>
> Yep, I got that.
> And I understand this one, most proba
On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
wrote:
> Hello,
>
> How fast would you expect svn checkout to be from a server like one below?
> Considering eveyrthing on the server functioning as expected.
>
> Apache 2.2.3
>
> 128G mem
> 10G
> FSFS is local storage.
I don't see how this can b
On 08.07.2013 21:31, Stefan Sperling wrote:
> On Mon, Jul 08, 2013 at 03:56:33PM +0200, Stefan Sperling wrote:
>> On Mon, Jul 08, 2013 at 07:20:17PM +0700, Eugene Grosbein wrote:
>>> Please note passtype is "gpg-agent", not "simple". I do not have gpg-agent
>>> installed,
>>
>> Are you 100% sure a
I just had a commit fail midway on three different 1.8 clients without any kind
of error logged in the output, in the client's Event Viewer (Win7,) or on the
repo server's httpd logs (linux.) No dump file either. Starting with a fresh
checkout made no difference. There's no pre-commit hook.
Hello,
How fast would you expect svn checkout to be from a server like one below?
Considering eveyrthing on the server functioning as expected.
Apache 2.2.3
128G mem
10G
FSFS is local storage.
Thanks,
--Roman Naumenko
___
Thi
On Mon, Jul 08, 2013 at 03:56:33PM +0200, Stefan Sperling wrote:
> On Mon, Jul 08, 2013 at 07:20:17PM +0700, Eugene Grosbein wrote:
> > Please note passtype is "gpg-agent", not "simple". I do not have gpg-agent
> > installed,
>
> Are you 100% sure about that? svn shouldn't be using the gpg-agent
Guten Tag vinoth kumar,
am Montag, 8. Juli 2013 um 15:14 schrieben Sie:
> Currently, we are getting error:
> svn: E720003: Could not open the requested SVN filesystem
You should provide at least the relevant sections for svn from your
httpd configuration, there surely is some error wit
On Mon, Jul 08, 2013 at 07:20:17PM +0700, Eugene Grosbein wrote:
> Please note passtype is "gpg-agent", not "simple". I do not have gpg-agent
> installed,
Are you 100% sure about that? svn shouldn't be using the gpg-agent
password store if it cannot contact a running gpg-agent.
> nor need it. Of
Hi!
Short story: it seems for me, subversion-1.8.0 (and, perhaps, 1.7.0) has broken
support
for plaintext password storage.
Long story: I upgraded to 1.8.0, built it under FreeBSD 8.4-STABLE using fresh
ports collection.
I have local repository and run svnserve to access it. All runs just fine
Dear Sir/Madam,
Greetings !!!
I want to configure Apache subversion as server.
I have installed subversion and Apache and made settings (httpd.conf) to
host my repositories. I run the "test configuation" in Apache utility to check
the connection and it shows no error. However, whe
On Mon, Jul 08, 2013 at 13:40, Stefan Sperling wrote:
> You could rewrite history, creating copyfrom pointers in old revisions.
> Create a new repository, create the common ancestor branch in the first
> commit, create the other branches as copies, and then replay your existing
> history on top
Branko Čibej wandisco.com> writes:
>
> I did explain it was a design bug in Subversion on Windows that has been
> around more or less forever. What other kind of response did you expect?
>
Yep, I got that.
And I understand this one, most probably, won't be fixed tomorrow...
Though, I'm still
On Mon, Jul 08, 2013 at 11:30:28AM +0200, Eric Estievenart wrote:
> I'm currently investigating the details and implications of these horrors,
> but I feel we are a bit doomed.
You could rewrite history, creating copyfrom pointers in old revisions.
Create a new repository, create the common ance
Branko Čibej wrote on Fri, 05 Jul 2013 22:12:34 GMT:
> Can you confirm that all the branches created by copying (svn copy) from the
> source, as you've described in this diagram?
Damn you are right. Some unexperimented people thought years ago that they were
more clever than the system,
created e
On Mon, Jul 8, 2013 at 7:08 PM, Johan Corveleyn wrote:
> Also, check the version of the server. I think if you use a very old
> server, that server might not fully understand the "depth" nuances. So
> it's possible that this is just a back compat thing: the server will
> send everything, and the
On Mon, Jul 8, 2013 at 11:08 AM, Johan Corveleyn wrote:
> On Mon, Jul 8, 2013 at 10:43 AM, Miro Kropáček
> wrote:
>>
>> On Mon, Jul 8, 2013 at 6:35 PM, Tobias Bading wrote:
>>>
>>> You said you did an update yesterday, have you tried it with the latest
>>> 1.7 Tortoise release and a fresh worki
On Mon, Jul 8, 2013 at 10:43 AM, Miro Kropáček wrote:
>
> On Mon, Jul 8, 2013 at 6:35 PM, Tobias Bading wrote:
>>
>> You said you did an update yesterday, have you tried it with the latest
>> 1.7 Tortoise release and a fresh working copy?
>
>
> What I meant is that I'm not sure in which version I
On Mon, Jul 8, 2013 at 6:35 PM, Tobias Bading wrote:
> You said you did an update yesterday, have you tried it with the latest
> 1.7 Tortoise release and a fresh working copy?
What I meant is that I'm not sure in which version I had tried this, I
can't remember order of these two actions :) But
On 08.07.2013 10:24, Miro Kropáček wrote:
Hi Tobias,
You're right, a simple 'svn update' in 'trunk' or 'software'
should not pull in any directories of files outside of 'user'.
That should only happen if you run e.g. 'svn update --set-depth
infinity'. What Subversion version are
Hi Tobias,
You're right, a simple 'svn update' in 'trunk' or 'software' should not
> pull in any directories of files outside of 'user'. That should only happen
> if you run e.g. 'svn update --set-depth infinity'. What Subversion version
> are you using and on what platform?
>
It's Windows, the on
On 08.07.2013 01:06, Miro Kropáček wrote:
Hello,
I'm not subscribed to the list. I'd like to ask about one issue I'm
having. Let's say I've got a tree like this:
server/svn/trunk/software
server/svn/trunk/software/user
server/svn/trunk/software/wicked_filenames
server/svn/trunk/documentation
37 matches
Mail list logo
