On Tue, Mar 8, 2011 at 4:58 PM, Richard Hipp <d...@sqlite.org> wrote: > Given > the DAG before the push/pull, and the complete set of changes caused by the > push/pull, can you suggest an algorithm that will answer yes or no as to > whether or not a new fork was created? Bonus points if you can give me a > name for the fork. > > For some projects, the DAG contains over 100,000 nodes. We'd like to > compute the answers above without having to pull nodes off the disk > corresponding to check-ins that happened many years ago.
Some recalls would be needed. (For purpose of this dicussion, I will use "push" because this denotes the direction of the operation even if the actual action was a pull from the other end.) Ideally, the detection should be done on the instance that the commit was performed on because it likely has a smaller workload then the down stream instance. However, this requires the pusher also pull updates (either before of after the push - ideally before) to have "foreign" commit info to campare with. As for methodology, the number of queries could be minimized with a linked list. From the description of how Fossil utilizes SQLite, I assume there is a table of commits. Add 2 fields (if not already present), one identifying the parent commit and the other field identifying the next youngest commit with the same parent. Since the DB tables are built by traversing the artifacts in chronological order, it is easy to point each "new" commit record to the previous record with the same parent. Then as a s new commits are added during a sync/push/pull, "older siblings" are automatically detected. I have not worked out implementation details, but I think this would work with out overloading a Fossil instance. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
