On Feb 17, 2016, at 2:07 PM, Andy Bradford <amb-fos...@bradfords.org> wrote: > > Thus said Warren Young on Wed, 17 Feb 2016 08:51:32 -0700: > >> I still get the assertion failure. Also, after the failure, the >> stashfile table remains empty. So, the failure is happening before >> anything successfully gets stored. > > And yet, you are no longer able to get the assertion failure using the > stash-fixes branch?
I must not have been clear in my last post: the same symptom (assertion failure on stash) occurs with both trunk and your stash-fixes branch. I believe this is because either: a) Fossil is dying before it gets to the code that creates this table, evidenced by an empty return from ‘.schema stashfile’ at a ‘sqlite3 .fslckout’ prompt; or b) Fossil *is* creating the table, but then because it exits uncleanly, that change is rolled back by the next sqlite3 instance that touches the DB. >> I'm doing ``fossil mv --hard some/file.cpp other/file.cpp'' then >> attempting to stash all uncommitted changes. > > Ok, that's not exactly how I was doing it (I was using --soft). But, if > all you're doing is fossil mv, I don't see how you could ever hit the > constraint violation that you reported was the new behavior after using > stash-fixes branch? The constraint failure was with [fea4d80e] back when it was on the pending-review branch, before stash-fixes was created. I assume your schema change on that branch fixes the constraint failure, because it no longer occurs with the tip of that branch. So, would it be fair to say that this fix doesn’t illuminate the original assertion failure problem after all? If so, the good news is that this proves that the stash-fixes branch is worth merging, as it does fix a real problem, just not my immediate problem. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
