On 02.09.2014 23:49, David Given wrote: > Given the discussion in the other thread(s), I have been thinking about > pull requests. (I've also had a beer. You Have Been Warned.)
So the paperwork's finally come through and I'm able to work on this. Hurray! Same disclaimer above applies. I've put together a proof-of-concept prototype; it's in the dtrg-bundles branch. It's a tiny tool mainly written in SQL which, when given two repositories old.fossil and new.fossil, and an artifact in new.fossil, will spit out a git fast-export file which will reproduce that artifact in old.fossil. It works by calculating an rid exclusion list which is then thrown at fossil export --import-marks. Use it like this: $ test/make-bundle-data old.fossil new.fossil (this will create some potted test data) $ tools/exportbundle.sh old.fossil new.fossil ab45b4cd > bundle (this will generate the bundle; you'll need to look at new.fossil and pick an artifact ID. Tagnames are not supported) $ tools/importbundle old.fossil test.fossil bundle (this will clone old.fossil and apply the bundle to it) Now, this doesn't quite work yet. If you try this and look at test.fossil, the new grafted tree doesn't link up with the old tree. (And boy, does the timeline graph drawer get confused by this sometimes...) Looking at the git export files, it seems there is no information there to allow the importer to figure out where to graft the tree on. For example, here's the bundle produced by producing a bundle for 'New file' in the test data: ---snip--- blob mark :14 data 36 empty data more data even more data blob mark :20 data 9 new file commit refs/heads/trunk mark :17 committer dg <dg> 1413670593 +0000 data 26 Clone, add: even more data from :13 M 100644 :14 1 commit refs/heads/trunk mark :23 committer dg <dg> 1413670594 +0000 data 8 New file from :17 M 100644 :20 2 tag branchpoint from :17 tagger <tagger> 1413670593 +0000 data 0 ---snip--- (Also that last tag artifact shouldn't be there; pretend you haven't seen it.) You can see that the commit at :17 is supposed to inherit from :13, but of course :13 isn't in there. I've tried tweaking the search algorithm to emit :13 as well, in the hope that the artifact UUIDs will match up, but it doesn't work --- obviously the generated C card for :13 doesn't precisely match the existing card. This would seem to be an issue with incremental imports as a whole; what am I missing here? Please note that this is a *proof-of-concept*, and is never intended to be actually merged. The SQL needs simplifying and it's probably full of bugs. (I need to double-check that I'm not mixing rids from the old and new repositories, for a start.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Home is where, when you have to go there, they have to take you in." │ --- Cordelia Naismith (via Robert Frost)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
