On Sun, Sep 30, 2018 at 04:06:08PM +, Knauß, Tobias wrote:
> Hello,
>
> First, as suggested on the mailing list page, I should mention that I am not
> subscribed to the mailing list, so please add me in CC on the responses.
> I also don't know if the mailing list accepts HTML, so I chose plai
Hello,
First, as suggested on the mailing list page, I should mention that I am not
subscribed to the mailing list, so please add me in CC on the responses.
I also don't know if the mailing list accepts HTML, so I chose plain-text, but
this does not allow adding screenshots, so for convenience y
Overview of problem:
Using svn client 1.8.10 on Mac OSX 10.9.4, downloaded from wandisco.
When trying to sync trunk to a branch with the command: svn merge ^/trunk
I get the following error:
svn merge ^/trunk
svn: E195016: Reintegrate can only be used if revisions 3 through 6 were
previously merge
bug in SVN 1.8.3 and 1.8.4 - file locking
Hi everyone.
I got curious to see if they are using my VC6 build of Subversio a.k.a.
Win32SVN. And my suspision it true, it's the Win32SVN 1.8.4 build for Apache
2.4.x that's is included in the Bitnami Redmine Windows installer.
Building Wi
of
compiler (this is all theory at the moment of course)
-Original Message-
From: Steve Davis
Sent: 03 February 2014 15:35
To: 'Philip Martin'
Cc: users@subversion.apache.org <mailto:users@subversion.apache.org>
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file lo
4 15:35
To: 'Philip Martin'
Cc: users@subversion.apache.org
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
All of the Apache and Subversion binaries came from the Bitnami download. I
could ask their support people exactly what compiler was used if you think that
would he
-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: 03 February 2014 15:34
To: Steve Davis
Cc: users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Steve Davis writes:
> Response:
>
> svn: E200035: sqlite[S19]: LOCK.lock_token may no
Steve Davis writes:
> Response:
>
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
> svn: E200035: Additional errors:
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
I can generate this error with the 1.8 client by patching mod_dav_svn to
return 400:
Index: sw/subversio
Any further feedback very much appreciated.
Thanks - Steve
-Original Message-
From: Ben Reser [mailto:b...@reser.org]
Sent: 01 February 2014 01:39
To: Steve Davis; users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
On 1/31/14, 1:54 PM, Steve Davis wrot
[mailto:b...@qqmail.nl]
Sent: 02 February 2014 15:26
To: 'Ben Reser'; Steve Davis; users@subversion.apache.org
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
> -Original Message-
> From: Ben Reser [mailto:b...@reser.org]
> Sent: zaterdag 1 februari 2014 0
> -Original Message-
> From: Ben Reser [mailto:b...@reser.org]
> Sent: zaterdag 1 februari 2014 02:39
> To: Steve Davis; users@subversion.apache.org
> Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> On 1/31/14, 1:54 PM, Steve Davis wrote:
> &g
On 1/31/14, 1:54 PM, Steve Davis wrote:
> :: Attempted to lock the working file
> svn lock c:\dev\Testrepo\NewDoc.txt
>
> Response:
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
> svn: E200035: Additional errors:
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
What if
Hi -
I have been trying to pin down the cause of an issue my users are seeing when
using SVN. It's actually a Windows Server 2008 R2 (64 bit) Bitnami-Redmine
stack of SVN, but I've tried to scrape it back to the most basic levels during
debugging, to hopefully omit any Bitnami-related issues.
Hi Johan,
Thanks for replying. Yes, you are right. I tried using that command in
couple of ways.
And i got to know the concept of this.
Thank you.
On Fri, Jun 14, 2013 at 2:54 PM, Johan Corveleyn wrote:
> On Fri, Jun 14, 2013 at 11:18 AM, Michael Pruemm
> wrote:
> > Nikitha Annaji vayavyal
On Fri, Jun 14, 2013 at 11:18 AM, Michael Pruemm wrote:
> Nikitha Annaji vayavyalabs.com> writes:
>
>> I was trying to display the log message between the dates 2013-06-13 and
> 2013-06-14 by the following command "svn log -r {2013-06-14}:{2013-06-13}",
> if no one has committed from the mentione
Nikitha Annaji vayavyalabs.com> writes:
> I was trying to display the log message between the dates 2013-06-13 and
2013-06-14 by the following command "svn log -r {2013-06-14}:{2013-06-13}",
if no one has committed from the mentioned date then the log should be empty
but it is showing the last co
Hi,
I was trying to display the log message between the dates 2013-06-13 and
2013-06-14 by the following command "svn log -r {2013-06-14}:{2013-06-13}",
if no one has committed from the mentioned date then the log should be
empty but it is showing the last commit which is was committed on
2013-06-
On Wednesday 22 June 2011, Nuno Cruces wrote:
> I believe I have found a bug the subversion server.
>
> It seems that, after committing a MIME formatted file (such as the one
> attached), I can't do anything to the file.
>
> Committing changes, returns the following:
>
> Commit failed (details f
Can't reproduce with either neon or serf.
9,% $svn add recover.eml
A recover.eml
9,% $svn ci -madd
Adding recover.eml
Transmitting file data .
Committed revision 2.
9,% $svn up
Updating '.':
At revision 2.
9,% echo>>iota
9,% $svn ci -mappend
Sendingiota
Transmitting file d
Hello!
We've encountered a strange behaviour with our quite loaded (avg 1500 http
requests per sec) SVN server. The server (RHEL5) is serving SVN repositories
via https by Apache.
apache 2.2.9
subversion 1.6.5
neon-0.28.4-1
neon-devel-0.28.4-1
The problem is that occasionally couple of httpd pro
20 matches
Mail list logo
