On Wednesday, December 02, 2015 4:40 PM, Andy Bradford wrote:
Thus said Andy Gibbs on Tue, 01 Dec 2015 19:14:13 +0100:

I  am syncing  with a  single server,  and I  have made  sure all  the
clients  have the  same fossil  version as  the server  (actually I've
upgraded them  all to the  latest released  version). I have  even run
"fossil  rebuild" on  all  checked-out repositories  and  also on  the
server.

Did  you upgrade  them prior  to the  problem happening  or after?  What
version were they before the upgrade?

I upgraded after the problem occurred.  I was running 1.32 on the server
and 1.32 or 1.33 on the clients.  All are running 1.34 now.

Stupidly, I didn't think to keep a copy of the repository files before
using --verily.

I can certainly let you know when (if?) it happens again.  What can I say
about my usage patterns? ... I am certainly doing large check-ins, for
example, modifying 100s of files at once.  A raw check-in manifest file
could easily be in the order of 4 MB in size.  I am not, however, using
private branches or shunning artifacts.  I have around 20 public branches,
but most are closed.  Branch check-ins tend to be small in comparison.

Does this help?

There  was  a  known  bug  where   a  large  commit  (by  large  I  mean
the  number  of artifacts  in  the  commit)  would cause  sync  problems
because  some  cluster artifacts---which  are  primarily  used for  sync
optimization---would get  lost in the  chain on the server.  Because the
server lost track of a cluster  artifact, some subset of artifacts would
never be requested for synchronization by the client.

This was fixed and  as far as we know it hasn't  happened again. Here is
the previous discussion which eventually led to a fix:

http://marc.info/?t=144565831000001&r=1&w=2
http://marc.info/?t=144565832800004&r=1&w=2

If you can  cause it to happen  while running the latest  Fossil on both
the server and  clients (after having used --verily to  bring in all the
artifacts) it would be appreciated if you can provide steps to reproduce
it.

Thanks,

Andy
--
TAI64 timestamp: 40000000565f112a



_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to