On 2/12/2016 11:53 AM, Ross Berteig wrote:
While comparing to a similar sequence with an added f3 instead of a
rename, I noticed another anomaly which I will try to paint into a
corner next.
Ok, I chased this into a corner with a test case, and got all the way to
the corner apparently without a bug.
I now believe that what I saw was by design. In a clean repo with files
f1 and f2 added and committed, I created and added a new file f3. Then I
did fossil revert, which said "UNMANAGE f3" but *did not delete the
file*. Subsequent testing via the test-stash command made note of f3
because it was still present in the file system.
After considering, I strongly suspect this is by design.
Fossil help revert is silent on the effect of reverting fossil add,
other than to say "Revert to the current repository version of FILE, or
to the version associated with baseline REVISION if the -r flag appears."
While revert generally is intended to destroy information (revert all
changes does that) it could be argued that reverting add by simply doing
UNMANAGE is the least action to take.
On the other hand, that could lead to surprises. The fossil regression
test suite is made up of test/*.test, regardless of whether those files
are managed by fossil or not. Adding a test file, then reverting to
remove it would not change what tests are run *in that workspace*.
So the ghost I thought I saw was extra references to f3 after it was
already out of the picture. I think that was the intent of the current
implementation. But is it the right answer? I don't know for sure.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
