But those intricate algorithms for deduplication, hash chaining, and
merging, those would come
in handy across the board.
A bit about drift: it's a natural outcome of parallel codebases, even with
something like a common
standard. Without that, it's guaranteed, unless one of the forks doesn't
get used.
Just a thought (probably stupid, since I haven't started to study fossil
and libfossil codebases yet):
Is it possible and feasible (i.e. will it have serious negative impact
on performance and resources usage) if fossil internal representations
and algorithms gradually be ported to collection, UDFs, VTables and
sqlite memdb tables where needed?
If the above is possible, both fossil(1) and libfossil core layers could
be written in SQL using the same sqlite extensions (eventually sharing
big portions of the code).
Kind Regards,
Alek
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
