Thus said Ross Berteig on Wed, 02 Mar 2016 15:20:52 -0800: > One of the changes was to the schema of the table used by the stash in > the local (per checkout) database, which was going to require that > every open checkout be re-opened.
This is only if they want to be able to stash a rename in their existing checkout. The change is backwards compatible, in the sense that the schema is already recorded in their .fslckout file and the code will continue to work with it. They just won't be able to stash a rename. If it is important enough for them to have the ability to stash renames, Fossil is flexible enough that they can just open a new checkout and stash their changes there. This allows them to slowly migrate out their stashes. > 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? 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? > 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. Again, because Fossil allows one to open the same repository in different paths in ones filesystem, as long as people know about this new behavior they can decide whether or not it is worth it to close their repositories, or to open a new checkout of their repository with a new stash schema. Should more code be added to automatically change the schema? Can a different solution be found that doesn't involve changing the schema? Thanks, Andy -- TAI64 timestamp: 4000000056d7a3a7 _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
