On Sun, Aug 18, 2013 at 05:20:35PM +0200, Michai Ramakers wrote: > > 1) on host S: clone project from host S (http://S/my_repo) > 2) on host C: clone project from host S (http://S/my_repo) > 3) on host C: do some work, and commit changes > 4) on host S, 'fossil up' > 5) on host S: 'fossil timeline' doesn't show the recent commit > 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil > timeline' > 7) on host C: do more work, and commit changes > 8) on host 'S': 'fossil up'; now all recent commits are seen > > Perhaps relevant info: > - autosync=1 on both sides > - host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd > - both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386 > - fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC > - fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC
Just to add some anecdotal data to this . . . I've seen this behavior recently as well, in very similar circumstances. The major difference has been that both clients have autosync turned off, and do a manual sync before hacking on code, and either a pull before pushing commits or a manual sync. Running "fossil update" after a sync or pull that brings in changes that, in turn, do not show up in the client's checkout directory does not solve the problem, if I recall correctly. It has only happened a couple of times, and both times was fixed by a merge on one side or the other or a reclone. Unfortunately, I have not been able to determine whether any particular pattern of using manual sync or pull has an effect on this. Note that, as I said, it has not happened much, so I have not had much opportunity to identify the conditions specific to the manifestation of the problem with any certainty, apart from what I have mentioned above, which is why I had not composed a question myself about this issue yet. This situation concerns us because the workflow we use may lead to problems if a failure of Fossil to properly deliver commits leads to new code being added in a non-merged way without developers noticing. The server is running Fossil v1.26 (from ports) on FreeBSD 9.0 amd64, one client is running Fossil v1.26 (from ports) on FreeBSD 9.1 amd64, and the other client is running an unknown version of Fossil (from packages) on Arch Linux amd64, I believe, though I will check on the Fossil version when that developer is available and double-check the installed OS with him as well, and share that information if it is deemed relevant. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
