On 6/26/2015 9:39 AM, Jan Nijtmans wrote: > 2015-06-26 6:31 GMT+02:00 Andy Goth <andrew.m.g...@gmail.com>: >> Is there any interest in making fossil clean be an undoable operation? >> If fossil revert is undoable, why not fossil clean? > > I already implemented that, feel free to experiment with it: > <http://fossil-scm.org/index.html/timeline?r=undo-clean>
Thanks, that's an excellent starting point. I took the liberty of merging trunk into your branch. It compiles, runs, and seems to work. Side note. The only merge conflict (there were two) that had me scratching my head was due to an end-of-line whitespace difference. In Vim I diff'ed the merge (trunk) and baseline (common ancestor) versions, and it highlighted the space character at the end of one of the baseline lines. Has anyone thought about giving fossil merge -w and -Z options like fossil diff has? > The problem is that this function might make the _FOSSIL_/.fslckout > file much much bigger, e.g. when a lot of built files are cleaned. > This can be improved by handling the following files differently: > 1) files matching "glob-ignore", those will be removed without > the possibility to recover. > 2) files > 10M (is this a good value?), those will be prompted for, > before removing them forever. > > I never really needed that, therefore I didn't do enough with > it to thrust it for 100%. But if it's usefull to you, I'm happy about that. I was a bit surprised that you explicitly make the -f option inhibit undo. I would have done otherwise. For a moment I considered saying that it shouldn't matter that the .fslckout file grow huge because its size increase is matched by a decrease in the size of the rest of the checkout. But then I realized that if the cleaned files are generated files, they're likely to be regenerated very soon, so the checkout will grow again while .fslckout remains the same. Following that reasoning, it indeed makes sense to not save backups cleaned ignore-glob files. But take another step and recall that the clean command also honors ignore-glob and will not delete them, sort of -verily or -x. Which implies -f. Which you explicitly do not support. As for the size limit, you present one option: confirming whether or not to back up files larger than ten megabytes. A refinement would be to make this threshold a setting. Or I think the setting could be an overall size limit on the undo backup, so having ten million one-byte files would also prompt. Or allow the user to pick both per-file and overall limits on the theory that huge files are often not worth saving (could be re-downloaded or regenerated since they're rarely made by hand... well maybe they could be user-created photos or videos...), but also large collections of comparatively small object files are also not worth saving. In my opinion, the previous paragraph is merely a failsafe against the case of the user not correctly setting ignore-glob. No conclusions, just getting some thoughts in writing. Will revisit when I have time. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
