I will change it, thank you, but I should mention, KeepAlive is off by
default on Redhat EL/Fedora and derivatives.
On Tue, Jul 2, 2013 at 3:50 PM, Lieven Govaerts wrote:
> Hi,
>
> On Tue, Jul 2, 2013 at 9:38 PM, Vadym Chepkov wrote:
> > Bert,
> >
> > Maste
** **
>
> If that is the case, it looks like this issue will be resolved with the
> next serf release. (Which should happen with or before Subversion 1.8.1).*
> ***
>
> ** **
>
> Bert
>
> ** **
>
> [Added CC to one of the serf develope
/!svn/rev/0': could not
connect to server (http://example.com)
Regards,
Vadym
On Mon, Jul 1, 2013 at 12:07 PM, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: Vadym Chepkov [mailto:vchep...@gmail.com]
> > Sent: zondag 30 juni 2013 22:58
> > To: R
On Jun 30, 2013, at 2:18 PM, Ryan Schmidt wrote:
>
> On Jun 30, 2013, at 07:06, Vadym Chepkov wrote:
>
>> After I upgraded to 1.8.0, svnsync process started to fail. I am using
>> apache 2.2.3. I suspect it's really serf's problem (1.2.1), but nevertheless
&g
Hi,
After I upgraded to 1.8.0, svnsync process started to fail. I am using apache
2.2.3. I suspect it's really serf's problem (1.2.1),
but nevertheless I had to revert back to 1.7.10. Is this a known limitation?
Thanks,
Vadym
On May 13, 2010, at 5:43 AM, Campbell Allan wrote:
>
> On Wednesday 12 May 2010, Vadym Chepkov wrote:
>> Consider this:
>>
>> $ svn -q --non-interactive update /blah-blah
>> $ echo $?
>> 0
>>
>> No output even to stderr, no indication of a f
asant surprise)
Vadym
On May 12, 2010, at 9:28 AM, Andy Levy wrote:
> On Wed, May 12, 2010 at 09:23, Vadym Chepkov wrote:
>> Hi,
>>
>> I think the exit code subversion returns isn't right, it should indicate an
>> error
>>
>> $ svn --version
Hi,
I think the exit code subversion returns isn't right, it should indicate an
error
$ svn --version
svn, version 1.6.11 (r934486)
$ svn update /blah-blah
Skipped '/blah-blah'
$ echo $?
0
$ svn update /etc
Skipped '/etc'
$ echo $?
0
Vadym
> [b2]$ svn merge --dry-run ^/branches/b1
> --- Merging r2 through r4 into '.':
>C README
> Summary of conflicts:
> Tree conflicts: 1
and yet another strange thing about it.
There is no way to automatically resolve a conflict like this.
no matter what flag I use --accept mine-conflict, mine
On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote:
>
> [b2]$ svn merge --dry-run ^/branches/b1
> --- Merging r2 through r4 into '.':
>C README
> Summary of conflicts:
> Tree conflicts: 1
>
>
> After r3, you'll need to do a '--record-only' merge of r4 into the second
> branch:
>
> (unte
;
Sendingb1
Adding b1/README
Committed revision 4.
[b2]$ svn merge --dry-run ^/branches/b1
--- Merging r2 through r4 into '.':
C README
Summary of conflicts:
Tree conflicts: 1
Thanks,
Sincerely,
Vadym Chepkov
11 matches
Mail list logo