On 2/10/2016 7:35 AM, Warren Young wrote:
....
However, this nonstandard option is not at fault per se. This also triggers it
with a default build:
mv foo.c bar.c
f mv --soft foo.c bar.c
f stash
So, the problem is trying to stash a renamed file.
Given this nice, concise, and obviously minimal script to cause fossil
stash to fail, I added it to our regression tests. First I had to create
test/stash.test which I modeled after test/revert.test since there are
huge similarities between fossil stash save and fossil revert both in
function and in output.
Two interesting results turn up from that effort.
First, I don't reproduce the assertion failure on my 32-bit Windows
build. This might not be surprising at all, it could absolutely be a
quirk of having 32-bit integers and 64-bit pointers as documented for
the OP's configuration.
Second, I don't get a stash saved at all.
My case starts from a clean checkout that has three unedited files. It does
fossil mv --soft f1 f1new
which as expected renamed the file in the repository but not on the
disk. It then says
fossil stash -m "B 2016-02-09"
which says
ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new
and does not create any stash entry.
What was fossil stash supposed to do in this circumstance? The early
test case (modeled after fossil revert's behavior) modeled the stashed
rename oddly as well, but at least it did model it.
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
