>svn ci -m "svn lock trouble" .
svn: Commit failed (details follow):
svn: Can't get exclusive lock on file
'/media/stuart/svn/ca/db/txn-current-lock': No locks available
I had done a svn mkdir and svn moved a bunch of files to it plus adding
some more - is that r
entire working directory? I am essentially dead in the
water here, as I cannot do any Subversion work in any directory.
On site, work is being done to rename or delete the offending files, but that
will not help me in my local build area on my PC.
Suggestions welcome.
Stuart Strickland
Software
x27;D:\Development\SVN\Releases\TortoiseSVN-1.14.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
---
OK
---
Brian Stuart | Engineering Manager
Smith Micro Software, Inc. | 120 Vantis,
I am seeing exactly this issue:
https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but do
not find a bug report for it in the database. The linked bug is for
something similar but unrelated. Can I file this?
...Stu
stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --vers
is clearly two
bugs: 1) the error message is wrong, 2) the client is dropping the
connection. Those need to be in the bug database unless they are already
present, or already fixed. Neither seemed to be the case when I posted.
...Stu
On Mon, Dec 16, 2013 at 11:59 AM, Mark Phippard wrote:
> On
shows "Server:
nginx/1.0.5". Client operation is 'svn up'.
What else would you like me to do/provide?
...Stu
On Mon, Dec 16, 2013 at 12:05 PM, Ben Reser wrote:
> On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote:
> >
> > I am seeing exactly this
> >
IT says we have:
nginx 1.05 with plans to move to 1.3.9
svn is 1.7.7 (we are not planning to upgrade for some time)
...Stu
On Mon, Dec 16, 2013 at 12:45 PM, Stuart MacDonald wrote:
> The link I provided is *exactly* what I'm seeing, so I didn't see the need
> to repeat that p
Thanks, I'll pass it along. It mentions that commit access is required to
exploit this though, so I think IT will probably ignore this if they
haven't already patched it.
...Stu
On Mon, Dec 16, 2013 at 2:20 PM, Ben Reser wrote:
> On 12/16/13 11:08 AM, Stuart MacDonald wrote:
>
On Mon, Dec 16, 2013 at 12:45 PM, Mark Phippard wrote:
> On Mon, Dec 16, 2013 at 12:31 PM, Stuart MacDonald <
> stuartm.cod...@gmail.com> wrote:
>
>> If someone can point me at a Ubuntu-compatible package, I'm more than
>> happy to upgrade. Last time I looked (w
On Monday, December 16, 2013 1:45:11 PM UTC-5, Branko Čibej wrote:
>
> So your server is using an nginx proxy, and your 1.7 client doesn't work
> with it. The thing to do is to try to reproduce this with 1.8, and if it's
> reproducible, it's still most likely a proxy bug (nginx 1.0.5 is rather
On Mon, Dec 23, 2013 at 3:51 PM, Lieven Govaerts wrote:
> to be clear, you've tested:
> - svn 1.7.13 with ra_neon, svn 1.7.14 with ra_neon and 1.8.5 with ra_serf.
> - to an svn 1.7.7 server
> - over http, with nginx 1.0.5. as intermediate proxy
> - running 'svn up'
> - on an Ubuntu guest (version
On Mon, Dec 23, 2013 at 4:47 PM, Stuart MacDonald
wrote:
> I took some time last Fri to see what was 180 seconds prior to the FIN
> packet in the trace (this is the 1.7.14 failure):
> 289223259.41852100010.222.3.8810.14.10.32HTTP1434
> Continuation or non-HTTP traf
I don't have access to the server log, but you can see from the wireshark
capture that the *client* closed the connection (look for the RST packet),
not the server. The error of "socket closed" is consistent with that.
I suspect that there's an issue handling the "http-timeout" timer; it gets
trig
re two interesting things:
The long gap after the *REF* packet is unusual, it's the first time I've
seen that.
The FIN packet is 72 seconds later, not 67 like I set the timeout. OTOH,
it's close, and, given the long gap no packets occur at FIN - 67 seconds.
I'm going to keep tryin
*The tagged 1.8.10 source on the main repo is fine and correct.*
So it looks like the source download build got corrupted somehow.
Regards,
Stuart
--
Stuart Rossiter
stuart.p.rossi...@gmail.com
Research Fellow: EPSRC Care Life Cycle Project
that's tested on several platforms.
> However, you may have received an unofficial or hacked tarball from
somewhere.
Yes, I'm using it fine; just wanted to flag that the 'official' source is
corrupt (maybe the tar-based ones are OK).
Stuart
On 6 November 2014 16:39, Bran
ay... Many apologies. (Turns away to hide reddening face...)
Stuart
P.S. If anyone is still reading (and does not yet hate me), I had a
tangential question about whether there is anything on Windows which
provides a binary install of the JavaHL JAR *and* native libraries (as
occurs in Linux packages such
17 matches
Mail list logo
