716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
|
that it is about to add a new check-in as a child of the
CHECKIN-HASH check-in and on the same branch as CHECKIN-HASH.
If some other client has already indicated that it was also
trying to commit against CHECKIN-HASH, that indicates that a
fork is about to occur, and the server will reply with
a "ci-lock-fail" pragma (see below). Check-in locks
automatically expire when the check-in actually occurs, or
after a timeout (currently 24-hours but subject to change).
<li><p><b>ci-lock-fail</b> <i>LOGIN MTIME</i></p>
<p>When a server receives two or more "ci-lock" pragma messages
for the same check-in but from different clients, the second a
subsequent ci-lock will provoke a ci-lock-fail pragma in the
reply to let the client know that it if continues with the
check-in it will likely generate a fork. The LOGIN and MTIME
|
|
|
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
|
that it is about to add a new check-in as a child of the
CHECKIN-HASH check-in and on the same branch as CHECKIN-HASH.
If some other client has already indicated that it was also
trying to commit against CHECKIN-HASH, that indicates that a
fork is about to occur, and the server will reply with
a "ci-lock-fail" pragma (see below). Check-in locks
automatically expire when the check-in actually occurs, or
after a timeout (currently one minute but subject to change).
<li><p><b>ci-lock-fail</b> <i>LOGIN MTIME</i></p>
<p>When a server receives two or more "ci-lock" pragma messages
for the same check-in but from different clients, the second a
subsequent ci-lock will provoke a ci-lock-fail pragma in the
reply to let the client know that it if continues with the
check-in it will likely generate a fork. The LOGIN and MTIME
|