Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
> 2) The additional time spent in the fork-detection is negligible.
I too was concerned about the additional time that might be spent
checking and whether or not it would be worth the extra time. Thanks for
taking the time to profile it a bit to discover its impact.
> The fork in "dg-misc" is already there for more than a year without
> causing any harm. I really doubt the value of this WARNING, since
> there is no clue at all where the fork is. Most people won't have any
> idea why the warning was there, and what to do about it.
This is not how it works though. :-) Normal Fossil use does
not recommend making a new empty Fossil repository, changing the
project-code and then pulling the Fossil repository (clever way to
profile by the way). Recommended use is to begin a new clone with
``fossil clone.''
And if they are using clone, they will not see:
> ***** WARNING: a fork has occurred *****
Because the code that prints it has a condition:
if( (syncFlags & SYNC_CLONE)==0 && g.forkSeen ){
So, only after a repository has been cloned and there are new unresolved
forks will this warning be present during a sync. Nobody will know about
the fork in dg-misc after cloning unless they update to that branch, or
new code is committed that forks again at that same node.
> Maybe more valuable would be to adapt the /leaves page, so people
> searching forks have an easy way to do so.
I proposed this very thing a few days ago, and I think that this is
something that should be done regardless of the discussion on sync
warnings.
Now, regarding the rest of the discussion...
Clearly the primary concern is about the additional time people, some of
whom are potentially uninterested parties, will spend tracking down
forks. And perhaps also there is concern that the warning will become
the ``boy who cried wolf'' of Fossil causing many people to run to the
village to look for forks, but eventually resulting in a user base
wielding instead pitchforks ready to burn someone at the stake, because
the forks had already been merged.
This seems like something we cannot know a priori: will this negatively
impact all of us, or will it have negligible impact because it will
assist speedy handling of forks causing them to be handled before anyone
gets the warning?
What if the fork is intentially left unhandled? This means that all
parties will be alerted to the fact that there exists a fork because it
was intentionally left a fork. Is this acceptable? Will this be
confusing for anonymous or other users of a given repository when the
developers intentionally leave a fork and they get a warning about it
the next time they sync?
Forks are so rare in Fossil proper, that it's hard to use it as a
test-bed. There has only been 1 so far this year.
Feedback?
Thanks,
Andy
--
TAI64 timestamp: 40000000552d667a
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
