Thus said Donny Ward on Sat, 21 Jun 2014 17:29:07 -0700:

> I have two versions of my repository that I've saved from a while ago,
> the last  time I ran  into this syncing  issue. I've linked  them both
> here, hoping  that someone can  analyze them  and figure out  what the
> issue is.

Ok, the problem  appears to be that checkin a9b1344817  is not reachable
by  any clusters  in your  server  repository (there  are actually  6482
unreachable artifacts in this repository's cluster chain):

$ fossil test-clusters -R wilderness-chiselapp.fossil | grep a9b1344817
  6179 a9b134481708d615ee06bd4a80044fc88e517b5f

I believe this could potentially be the culprit:

http://www.fossil-scm.org/index.html/artifact/37f2afbbd186bf5cef90c57b7fa1acd7097977cd?ln=705

If  I understand  this correctly,  it will  delete from  the unclustered
table but leave behind any newly  added cluster artifacts that were just
created. But  what about  phantoms that might  exist in  the unclustered
table  at that  moment and  which  have not  yet been  added to  cluster
artifacts?

Perhaps this will correct it:

http://www.fossil-scm.org/index.html/info/41b29f38fdb4e5ed9e0313648160aca055c4eca0

It  won't   help  in  synchronizing   content  that  is   currently  not
synchronizing, however, I believe it will prevent phantom artifacts from
becoming orphaned in the cluster chain.

Comments?

Thanks,

Andy
-- 
TAI64 timestamp: 4000000053a91905


_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to