On Fri, Apr 18, 2014 at 11:01 AM, Tony Papadimitriou to...@acm.org wrote:
I have a global ignore-glob that applies to most fossil repos. But, on
occasion, I need to have an empty ignore-glob list for a specific
repository.
If I unset the local setting, then the global setting kicks in.
Just FYI, I'm seeing this kind of message quite often. This is due to
overlapping clone operations on large fossils on relatively slow disk.
Round-trips: 1 Artifacts sent: 0 received: 0 Round-trips: 1
Artifacts sent: 0 received: 109 Round-trips: 2
Artifacts sent: 0 received: 109 Round-trips: 2
This being Unix, there are a million ways to do things. Just for the
sake of curiosity, here are 0.0004% more of the possibilities. I only
bring this up because I know several of my coworkers don't know about
these tricks, so I imagine some others out there might not either.
On 4/18/2014 4:17
Sorry for the multiple mails but I have a little more info.
I can reliably reproduce this. Just do two simultaneous clones via ssh from
a large fossil. This is on NFS. It happens very quickly so fossil is giving
up pretty fast.
On Fri, Apr 18, 2014 at 8:52 AM, Matt Welland estifo...@gmail.com
On Fri, Apr 18, 2014 at 6:00 PM, Matt Welland estifo...@gmail.com wrote:
I can reliably reproduce this. Just do two simultaneous clones via ssh
from a large fossil. This is on NFS. It happens very quickly so fossil is
giving up pretty fast.
NFS w/ db file == fundamentally bad idea.
db.c
On Fri, Apr 18, 2014 at 9:21 AM, Stephan Beal sgb...@googlemail.com wrote:
NFS w/ db file == fundamentally bad idea.
db.c sets the default budy timeout to 5 seconds.
So you are recommending we abandon fossil because of this? Storing the
files on local disk is not an option for us. Also,
On Fri, Apr 18, 2014 at 6:47 PM, Matt Welland estifo...@gmail.com wrote:
So you are recommending we abandon fossil because of this? Storing the
files on local disk is not an option for us. Also, other than being a
little slow, storing fossils on NFS has not been an issue.
Search this page
On Fri, Apr 18, 2014 at 12:47 PM, Matt Welland estifo...@gmail.com wrote:
I did some more testing and this is unique to using ssh and it occurs on
local disk just as fast as on NFS.
I don't have NFS set up anywhere so I cannot test that. But I can do
multiple ssh clones from a different
NFS is not needed to reproduce this. Simultaneous parallel cloning via ssh
from one file is giving me this every single time.
Could it be an OS dependency? I'm on SuSe Linux (SLES11).
I downloaded the binary from fossil-scm.org and tested again and get
exactly the same issue.
I do happen to be
On Fri, Apr 18, 2014 at 1:32 PM, Matt Welland estifo...@gmail.com wrote:
NFS is not needed to reproduce this. Simultaneous parallel cloning via ssh
from one file is giving me this every single time.
Could it be an OS dependency? I'm on SuSe Linux (SLES11).
I downloaded the binary from
How big is the repo? The one I'm cloning is 420 MB. Perhaps that is a
factor?
On Fri, Apr 18, 2014 at 10:39 AM, Richard Hipp d...@sqlite.org wrote:
On Fri, Apr 18, 2014 at 1:32 PM, Matt Welland estifo...@gmail.com wrote:
NFS is not needed to reproduce this. Simultaneous parallel cloning
On Fri, Apr 18, 2014 at 1:41 PM, Matt Welland estifo...@gmail.com wrote:
How big is the repo? The one I'm cloning is 420 MB. Perhaps that is a
factor?
I was using SQLite, 55MB. The biggest repo I have at hand is
System.Data.SQLite at 264MB. I just did three simultaneous ssh clones of
it
On Fri, Apr 18, 2014 at 10:03 AM, Stephan Beal sgb...@googlemail.comwrote:
NFS is historically problematic when it comes to file locking.
This is true. However technology doesn't stop evolving. The locking on NFS
on the systems I use seems pretty rock solid. I push sqlite3 to extremes on
NFS
On Fri, Apr 18, 2014 at 01:50:08PM -0400, Richard Hipp wrote:
On Fri, Apr 18, 2014 at 1:41 PM, Matt Welland estifo...@gmail.com wrote:
How big is the repo? The one I'm cloning is 420 MB. Perhaps that is a
factor?
I was using SQLite, 55MB.A The biggest repo I have at hand
On Fri, Apr 18, 2014 at 11:51 AM, Andy Goth andrew.m.g...@gmail.com wrote:
which is a no-op (does nothing, successfully):
Being in the world of bare silicon, this gave me a chuckle. does
nothing, successfully has a side effect, therefore actually does
something. Specifically, it declares
Thus said Matt Welland on Fri, 18 Apr 2014 08:52:09 -0700:
Round-trips: 1 Artifacts sent: 0 received: 0 Round-trips: 1
Artifacts sent: 0 received: 109 Round-trips: 2
Artifacts sent: 0 received: 109 Round-trips: 2
Artifacts sent: 0 received: 773 Round-trips: 3
Artifacts sent: 0 received: 773
Thus said Matt Welland on Fri, 18 Apr 2014 10:32:26 -0700:
Could it be an OS dependency? I'm on SuSe Linux (SLES11).
No, I can reproduce it on OpenBSD. I'm looking at it more closely to see
what might be causing it. Basically, you need a long commit in progress
and then try to sync. I can
Thus said Matt Welland on Fri, 18 Apr 2014 10:41:39 -0700:
How big is the repo? The one I'm cloning is 420 MB. Perhaps that is a
factor?
No, the problem appears to be the difference between using test-http and
http as the remote command. The default behavior for the Fossil client
is to send
Thus said Andy Bradford on 18 Apr 2014 18:56:09 -0600:
Everything works as expected (e.g. no locking issues).
I spoke too soon. If I give the Fossil user permissions (e.g. don't
clone as nobody) then the issue arises again.
It doesn't appear to be isolated to just SSH. I can cause
19 matches
Mail list logo
