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?
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
