We've had several folks get very confused by the accidental creation of
forks. The conversation goes something like this:
DeveloperA: "Go ahead and update, I've checked in change xyz"
DeveloperB: "Ok" (pause) "I don't see it are you sure you checked it in ...
"
and fifteen minutes later I get a call ... "Matt, fossil is broken ..." and
I get to explain forks, how they happen and how to fix them :-)
The problem is that forks can be silently created by disconnected
operations and can lie hidden for some time. To mitigate this we added fork
detection to the wrapper for the following operations: changes, status,
update, timeline and co.
matt@xena:~/data/fsl$ fsl stat
WARNING!!! Fork detected on trunk, use "fsl leaves" and "fsl merge" to find
and correct.
repository: /home/matt/fossils/fsl.fossil
local-root: /home/matt/data/fsl/
checkout: f6ef89b074d9ac02f00074b1bd03b0d52686306a 2012-05-01 04:26:18
UTC
parent: 2a1ded8b0beac4b1d8d64b00cee7c7e5870dbe50 2012-05-01 03:28:14
UTC
tags: trunk
comment: Manually merged in the fork detection code. Also make most
options work with partial match (user: matt)
(P.S. thanks go to Jeffery Gong for figuring out the necessary SQL snippet)
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
