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,
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
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
*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
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
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
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
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 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 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
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:
>
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
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
> >
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
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
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
>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
17 matches
Mail list logo
