With the help of the excellent documentation on the Fossil Sync
Protocol I have found a very simple solution to fix synchronization of
unversioned files. Due to how work is distributed between the server
and the client, it's correct that the server ignores "uvigot" cards,
but the client should stop sending them.

http://www.fossil-scm.org/index.html/doc/trunk/www/sync.wiki

I would like to suggest a solution in prosaic form, so you can add it
to Fossil without any copyright concerns, if you think it's useful:

In the client synchronization code, merge the test for the break
condition whether the send limit has been reached with the entry test
for the `while' loop, so that the loop is only entered if the size of
the output blob is LESS THAN the send limit AND `db_step()' returns
SQLITE_ROW.

http://www.fossil-scm.org/index.html/artifact/0d5ab26abb?txt=1&ln=1934

Like this, send_unversioned_file() is only called by the client if
there's room for one more file, and no "uvigot" cards will be
generated. By not entering the loop, the skipped unversioned file
remains in the `uv_tosend' table to be sent later, and `uvDoPush'
remains 1 as `db_step()' is not called before assuring there's enough
room.

Testing if the output blob size is LESS THAN the send limit does not
allow the output blob to grow as large as the send limit, whereas
before it was allowed to grow up to the send limit. But
`send_unversioned_file()' takes the "uvigot" path if the output blob
is GREATER THAN OR EQUAL the send limit, so the changed `while'
condition uses the same limits as `send_unversioned_file()'.

I'm not sure however if "max-upload" can be assumed to always be
greater than zero. Through the web interface, "max-upload" can be set
to a negative number, so it may be safe to make sure "max-upload" is
greater than zero when reading the value from the configuration.

http://www.fossil-scm.org/index.html/artifact/0d5ab26abb?txt=1&ln=1745

--Florian
_______________________________________________
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