On 3/2/2016 6:37 PM, Andy Bradford wrote:
Thus said Ross Berteig on Wed, 02 Mar 2016 15:20:52 -0800:
....
Would it be preferred for fossil stash to check for that schema change
and automatically fix the open checkout if needed?
Possibly, but that is a lot of newly originated code for something like
this---we're kind of in new territory I suppose. Has the schema of the
.fslckout ever changed? If yes, how was it handled?
Yes, apparently it has. In isValidLocalDb() in src/db.c ca. line 1099,
there are two if blocks that test for some feature of the local db
schema, and to the needed ALTER TABLE commands to fix things up.
I imagine you would just need to figure out how to ask if the right
column is the index and fix it, and that is the place to do it.
How long has stash been around with the inability to stash a rename?
Perhaps you're right though. It might be slightly confusing to worry
about multiple versions of stash files out in the wild?
Going out on a limb with a guess here, but given that the test suite had
0% coverage of stash.c it seems safe to guess that stash has never
handled renamed files perfectly.
I am slightly puzzled about the stash tables having schema defined in
stash.c and only applied when stash is first used. The rest of the
schema for the three important database files are all in schema.c. At a
guess, someone wasn't sure that stash was a first class feature and kept
its implementation entirely self-contained.
As I understand it, "fossil close && fossil open" would result in loss
of an existing stash.
Only ``fossil close -f && fossil open'' would result in loss. :-)
We need the fix for rename, but it should be gentler for a user.
I would say it's pretty gentle as-is, but I certainly think more eyes
looking at it would be good and I'm also not opposed to not merging if
it is deemed too risky and needs more work.
Aside from the schema update, which I think does have a fairly painless
fix, I'm fine with getting this fixed.
....
Should more code be added to automatically change the schema? Can a
different solution be found that doesn't involve changing the schema?
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
