That makes sense, but what I'm saying is, why bother with the compile-time flag?
It seems desirabe to allow the user to configure this behavior with repository settings, rather than using a flag to determine if it is hard-coded or not. Are there a lot of legacy scripts out there that are difficult to modify? Perhaps keeping the new behaviour (overridden with --soft) is worth it at this stage. On Wed, 20 Jun 2018 21:49:18 -0400 Richard Hipp <d...@sqlite.org> wrote: > It ought to be the case that the default action of "fossil rm" and > "fossil mv" is to actually change the filesystem, in addition to > changing the way files are stored in the repository. But early > versions of Fossil did not behave that way. They required you to do > it in two steps: > > fossil rm abc.c > rm abc.c > > We talked about fixing Fossil so that "fossil rm abc.c" actually > removed the file. But the feeling was that would break too many > legacy scripts. So the less desirable legacy behavior remains, to > this day. > > On 6/20/18, bytevolc...@safe-mail.net <bytevolc...@safe-mail.net> wrote: > > Hello, > > > > I am trying to understand the idea behind FOSSIL_ENABLE_LEGACY_MV_RM. > > > > It has been around for a while, and it is the only compile-time flag that > > determines if a setting is hard-coded or if it is obtained from the > > repository config. > > > > It appears that if this is not defined, the "mv" and "rm" commands will > > modify the file system under all circumstances. > > > > Given the "--hard" option in these commands anyway, this seems superfluous. > > So what is the idea behind the FOSSIL_ENABLE_LEGACY_MV_RM flag? > > > > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
