Howdy,

I've gotten this error when trying to incrementally update a git repo:

$ /usr/bin/fossil export --git --import-marks fossil-marks --export-marks fossil-marks repo.fossil
Non-existent SHA-1/SHA-3 in marks file: facec13bc95a8fb41aa1ef53a256ff373bd9a43f6e21623e0b5f0993bbf17dce
error importing marks from file: fossil-marks

I've done some digging and think that my problem is that repo.fossil is not the original fossil repo used to first export to the git repo. Its blob table has uuid's mapped to different rid values to that of the original fossil repo.

Examining the failing repo, working repo and marks file (with fossil sql command banner text removed):

$ fossil sql -R repo.fossil
sqlite> select rid from blob where uuid = 'facec13bc95a8fb41aa1ef53a256ff373bd9a43f6e21623e0b5f0993bbf17dce';
91

$ fossil sql -R original-working/repo.fossil 
sqlite> select rid from blob where uuid = 'facec13bc95a8fb41aa1ef53a256ff373bd9a43f6e21623e0b5f0993bbf17dce';
107

$ grep facec13bc95a8fb41aa1ef53a256ff373bd9a43f6e21623e0b5f0993bbf17dce fossil-marks 
b107 :155 facec13bc95a8fb41aa1ef53a256ff373bd9a43f6e21623e0b5f0993bbf17dce

This check is failing because it's expecting rid == 107 (or so i think).

But is it needed? Am i right to assume that blob.rid values are specific to each fossil repo clone?

Anyway, i know nearly nothing about the inner workings of fossil, so i'd be grateful for any help here.

Cheers.

Some background info for anyone still reading: i have a number of machines (raspberry PIs, netbooks, desktops) that all have clones of my various fossil repositories.

For those fossil repos that i need to keep synced with git, i use fossil export --git .. storing their fossil and git marks files with the fossil repo as unversioned files hoping that i can use any cloned repo from whatever machine to do incremental updates to git.

But is it needed? Am i right to assume that blob.rid values are specific to each fossil repo clone?

i can't answer that first question but the second one is definitely true. blob.rid should never be used for anything but access to a repository's own data.

Thanks for the info Stephan, that's what i was hoping. And sorry for writing this so late, i got distracted by some shiny object and lost track of this one..

Here's a diff of the most minimal change that allows for exporting to git from any up-to-date fossil repo. Combined with this neat idea of storing marks as unversioned files, i can use any fossil clone to update git mirrors.

I've tested it with a couple of (previously failing) fossil repositories that used different rid/uuid mappings with success.

It's purposefully written to break style a little in case you wanted to adapt and include it in fossil. Or i can follow proper steps to submit if there's interest.

Index: src/export.c
==================================================================
--- src/export.c
+++ src/export.c
@@ -342,12 +342,16 @@
     return -1;
   }else{
     sqlite3_snprintf(sizeof(mark->uuid), mark->uuid, "%s", cur_tok);
   }
 
-  /* make sure that rid corresponds to UUID */
-  if( fast_uuid_to_rid(mark->uuid)!=mark->rid ){
+  /*
+   * Get rid that corresponds to UUID.
+   * vfile.c:fast_uuid_to_rid() returns 0 if UUID is not found.
+   */
+  mark->rid = fast_uuid_to_rid(mark->uuid);
+  if( mark->rid==0 ){
     free(mark->name);
     fossil_trace("Non-existent SHA-1/SHA-3 in marks file: %s\n", mark->uuid);
     return -1;
   }

I've tested it with a couple of (previously failing) fossil repositories that used different rid/uuid mappings with success.

Before checking this in, can someone familiar with the git export process confirm that the following patch is acceptable? It looks correct to my layman's eyes, but i've no even marginally convenient way to validate it:

Index: src/export.c
==================================================================
--- src/export.c
+++ src/export.c
@@ -310,5 +310,8 @@
     return -1;
   }
-  mark->rid = atoi(&cur_tok[1]);
+  mark->rid = fast_uuid_to_rid(mark->uuid)
+    /* forum post bfb325108171eb8b: we want export to work
+    ** even if the RIDs get re-mapped, e.g. a different clone
+    ** is used. */;
   type_ = cur_tok[0];
   if( type_!='c' && type_!='b' ){
@@ -346,5 +349,5 @@
 
   /* make sure that rid corresponds to UUID */
-  if( fast_uuid_to_rid(mark->uuid)!=mark->rid ){
+  if( !mark->rid ){
     free(mark->name);
     fossil_trace("Non-existent SHA-1/SHA-3 in marks file: %s\n", mark->uuid);

Achtung: there is a code path which calls return create_mark(mark->rid,...) before the if(!mark->rid) check is made, but it's not clear to me whether that check should also be moved up to the top of the function.

The smallest public domain repositories i have with divergent rid/uuids are roughly 260k each. I'd be happy to email them to you so you can use them in any way you like?

Ha! To clarify:

... but i've no even marginally convenient way to validate it

was less about availability of git repos to test and more about my complete inability to operate git for anything beyond "clone" and "pull" :/.

Maybe something like this?

i am unfortunately not certain. Though i'm relatively well-versed in most of fossil's internals, i admittedly willfully turn a blind eye to the git-related parts.

i.e. we'll need a genuine fossiler-gitter combo person to validate that fix.

i.e. we'll need a genuine fossiler-gitter combo person to validate that fix.

Ping, in the interest of getting this corrected before the 2.25 release.

i.e. we'll need a genuine fossiler-gitter combo person to validate that fix.

Another ping - this has been flagged as todo in my inbox for ages but i'm not qualified to judge the validity of the patch proposed up-thread.