On 2/17/2016 6:54 PM, Andy Bradford wrote:
Thus said Ross Berteig on Wed, 17 Feb 2016 15:18:12 -0800:
fossil mv --hard old new; touch old; fossil stash -m "both" fails to
stash with the SQLITE_CONSTRAINT message.
Not for me...
$ f ver
This is fossil version 1.35 [7ad8230273] 2016-02-15 17:43:10 UTC
$ f mv --hard old new; touch old; fossil stash save -m both
RENAME old new
MOVED_FILE /tmp/new/old
REVERT old
DELETE new
$
Andy
--
TAI64 timestamp: 4000000056c5327e
Sorry for the noise, that was a slightly different edge case which does
not throw an error: If, after a rename, the old file name has content
but is not added to the repo, then the stash succeeds, but it will
overwrite the new content in the old name without warning. I think that
is the right response, as it seems generally unsafe to have any valuable
content in an open workspace that is not under version control.
What I meant to say was that:
$ fossil mv --hard old new; touch old; fossil add old
$ fossil stash -m "Boo"
fails with the SQLITE_CONSTRAINT error with trunk, aka:
$ ./fossil version
This is fossil version 1.35 [7935571bea] 2016-02-17 22:10:58 UTC
I should add the other case to the tests, as well as the related case
with a fossil mv --soft and both names present on disk and added to the
repo to stash.test. I'll do that after I've admitted how late (early) it
is here in California.
--
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
