2015-04-14 5:46 GMT+02:00 Andy Bradford <amb-fos...@bradfords.org>:
> Thanks. One thing to note is that I extended the function
> fossil_find_nearest_fork to be able to work without checking the vmerge
> table which is only available for a repository that is open, however,
> fossil sync may actually be run with -R and there may or may not be a
> vmerge table for that.
>
> Perhaps a better option would be to check for the vmerge table if it
> exists and use it, otherwise don't?
I really don't know what would be best here. My only concern is the additional
time this check takes when syncing. So, let's do a little stress-test.
First create
an empty repository in which we are going to pull the complete content of
the fossil self-hosting repository:
$ fossil new z.fossil
...
$ fossil sqlite -R z.fossil
SQLite version 3.8.9 2015-04-08 12:16:33
Enter ".help" for usage hints.
sqlite> update config set
value='CE59BB9F186226D80E49D1FA2DB29F935CCA0333' where
name='project-code';
sqlite> .exit
So, now we can pull the full content:
$ time fossil pull -R z.fossil http://www.fossil-scm.org/index.html
Round-trips: 344 Artifacts sent: 0 received: 30646
Pull done, sent: 1124980 received: 19585724 ip: 67.18.92.124
real 27m21.480s
user 1m18.421s
sys 0m25.240s
Now, repeat the same steps but using fossil compiled from the
"sync-forkwarn" branch:
Round-trips: 362 Artifacts sent: 0 received: 30646
Pull done, sent: 1186697 received: 19659128 ip: 67.18.92.124
***** WARNING: a fork has occurred *****
real 25m49.494s
user 1m18.780s
sys 0m27.752s
Conclusion:
1) The fork-detection during sync works, the fork in the "dg-misc"
branch is detected correctly.
2) The additional time spent in the fork-detection is negligible.
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. I guess it will
only cause more confusion than that it helps people getting the
repository fork-free.
Maybe more valuable would be to adapt the /leaves page, so people
searching forks have an easy way to do so.
Just my 2c
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
