On 2/12/2016 5:39 PM, Warren Young wrote:
On Feb 12, 2016, at 5:09 PM, Ross Berteig <r...@cheshireeng.com>
wrote:
After considering, I strongly suspect this is by design.
Of course; reverting add should not remove the file. The file was
not always Fossil’s to do with as it pleased, so when we revert add,
we really mean “unmanage”. The file becomes someone else’s problem
again, as far as Fossil is concerned.
Yes. Fossil simply knows nothing about the previous lifetime of the
file, so it would be presumptuous to delete it when we revert the add
whether by revert or stash.
I’m not certain how this plays into the stash-rename problem, though.
f mv --hard tells Fossil something that f add does not: it tells it
both the old and new file names. The old file name belonged to
Fossil, and the new file name is *proposed* to belong to fossil, and
will become so on checkin. This is an expression of intent. When
you stash, that intent should be saved, and when you apply that stash
entry, the intent should be restored.
Yes. You've expressed my unease much better than I did.
Even fossil mv --soft expresses a similar intent. It has a different set
of edge cases related to when and how the file system is adjusted.
Imagine that file A and B are both present, but only A is managed. I
suspect that fossil mv --soft A B just means that the managed name
changed from A to B, which might also mean that the *content* associated
with that name just got edited if A and B's content differs.
So my other source of unease is that a sequence of actions in a working
folder: "checkout -- edit, debug, fuss, -- revert" might leave the
folder in a different state than it was just after the checkout. This is
most likely the natural result of any fossil adds, but renames,
compiling, debugging, etc. can certainly also create unmanaged files in
the folder. As long as fossil stash save and fossil revert would leave
the folder in the *same state* I think my unease is tamed.
If you really want a folder that looks like a fresh checkout of some
other tag or version, then you want update or checkout, or possibly even
open and checkout in a new location.
--
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
