I fwiw have always found Fossil's mv and rm semantics odd. The following
semantics are basically what I expected when I first started using Fossil,
but extended to preserve backward compatibility. They basically do what
the user intended in all cases, do they not?
* fossil rm FILE:
* If FILE is unmanaged, then error out (without deleting FILE).
* if FILE is managed but does not exist, then apply current semantics
(i.e. stage for removal at commit time).
* If FILE is managed and exists, then do a filesystem remove of FILE
and then apply current semantics.[1]
* fossil mv A B:
(1) if A is unmanaged, then error out.
(2) if A and B are both managed, then apply current semantics (i.e.
error out).
(3) if A is managed, A does not exist, and B exists but is not managed,
then then apply current semantics.
(4) if A is managed and A exists:
* if B does not exist, do a filesystem rename of A to B and then
apply current semantics (3)
* if B exists, then error out. (I am not a fan at all of the
current semantics, in which B is irrevocably deleted if initially unmanaged
after 'fossil mv A B; fossil revert', so am trying to smuggle a fix for
that in here:-)
Maybe I'm missing sub-cases, but the key thing is that I expect Fossil to
do the filesystem 'rm' or 'mv' for me if it's safe to do so. And I think
Fossil can preserve backward compat even if extended in this way, right?
Eric
[1] Consider first checking for changes against current check-in and
erroring out if file is 'dirty' (recommending revert first), which I think
Git does.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
