Re: [fossil-users] Amended check-in time

On 09/21/17 20:48, Andy Goth wrote: The second timeline has the corrected time: === 2017-09-22 === 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10

[fossil-users] Timeline tag format

On 09/21/17 20:48, Andy Goth wrote: 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) A digression. What is the purpose of showing the edited artifact ID twice with two different lengths? This output was produced by the timeline

Re: [fossil-users] Amended check-in time

On 09/21/17 19:51, Richard Hipp wrote: I don't have any idea [why] the tags are not working for you. Try this sequence: f new repo.fossil mkdir ckout cd ckout f open ../repo.fossil touch xxx f add xxx f commit -date-override 2018-01-01 -m 'add xxx' sleep 5 TIME=$(date +%FT%T) sleep 5 f rm

Re: [fossil-users] Amended check-in time

On 9/21/17, Andy Goth wrote: > On 9/21/2017 4:36 PM, Andy Goth wrote: >> I'm having trouble changing the time of a check-in using the Web >> interface or the amend command. Either way I get a good result in the >> repository I amended, but it doesn't seem to sync right.

Re: [fossil-users] Amended check-in time

On 9/21/2017 4:36 PM, Andy Goth wrote: > I'm having trouble changing the time of a check-in using the Web > interface or the amend command. Either way I get a good result in the > repository I amended, but it doesn't seem to sync right. When viewing > on other sync'ed repositories, the amended

Re: [fossil-users] uv add dir/filename

On 9/19/2017 9:20 AM, Andy Goth wrote: > Okay, I suggest refining the error message to not just say the filename > is unacceptable, but rather to explain the restriction, like is done > with whitespace. Done. http://fossil-scm.org/index.html/info/493e3bade9ae8dc6 -- Andy Goth |

[fossil-users] Amended check-in time

I'm having trouble changing the time of a check-in using the Web interface or the amend command. Either way I get a good result in the repository I amended, but it doesn't seem to sync right. When viewing on other sync'ed repositories, the amended time isn't always there. With the test I just

Re: [fossil-users] Continued issues with read-only repository

On 9/21/2017 4:13 PM, Richard Hipp wrote: > I think you can omit the IOERR_RETRY now. I believe I have fixed that > problem in the Windows VFS of SQLite. At least, it works for me on my > Win10 laptop when I set the repository file to read-only. Please try > it and let me know either way. Oh

Re: [fossil-users] Continued issues with read-only repository

On 9/21/17, Andy Goth wrote: > On 9/21/2017 3:48 PM, Richard Hipp wrote: >> The latest check-in >> (https://www.fossil-scm.org/fossil/info/e97d4443d5628702) loads a new >> version of SQLite which should address the issues of trying to open a >> read-only database file.

Re: [fossil-users] Continued issues with read-only repository

On 9/21/2017 3:51 PM, Richard Hipp wrote: > Your fix to the /doc webpage was also helpful, Andy. I had seen that > error before but then it went away mysteriously and I was wondering > what happened. Apparently I pulled in your fix while testing my > changes, without realizing it. :-) When

Re: [fossil-users] Continued issues with read-only repository

On 9/21/2017 3:48 PM, Richard Hipp wrote: > The latest check-in > (https://www.fossil-scm.org/fossil/info/e97d4443d5628702) loads a new > version of SQLite which should address the issues of trying to open a > read-only database file. Please try it and let me know. Looks good to me, provided I

Re: [fossil-users] Continued issues with read-only repository

On 9/21/17, Richard Hipp wrote: > On 9/21/17, Andy Goth wrote: >> >>> As an interim fix, can you recompile with -DSQLITE_WIN32_IOERR_RETRY=0 >>> and let me know if that clears the problem for you? >> >> This improves matters but doesn't totally fix

Re: [fossil-users] Continued issues with read-only repository

On 9/21/17, Andy Goth wrote: > >> As an interim fix, can you recompile with -DSQLITE_WIN32_IOERR_RETRY=0 >> and let me know if that clears the problem for you? > > This improves matters but doesn't totally fix everything. Fossil starts > far faster and no longer has the

Re: [fossil-users] Continued issues with read-only repository

On 9/21/2017 3:17 PM, Andy Goth wrote: > The winOpen() function then successfully retries with flags altered to > contain SQLITE_OPEN_READONLY instead of SQLITE_OPEN_READWRITE, and this > succeeds. Trouble is, winLog() was already called, and the error > message propagated back to Fossil and

Re: [fossil-users] Continued issues with read-only repository

On 9/21/2017 1:18 PM, Richard Hipp wrote: > The problem is that the Windows VFS has logic that retries failed I/O > operations repeatedly before giving up. This is a work-around to the > common issue of anti-virus software holding files hostage while they > are being scanned. It was a mistake to

Re: [fossil-users] Continued issues with read-only repository

On Sep 21, 2017, at 11:16 AM, Andy Goth wrote: > > xyzzy...Nothing happens. You win 10 geek points today. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org

Re: [fossil-users] Continued issues with read-only repository

On 9/21/17, Andy Goth wrote: > > To reproduce, all that's needed is to set the repository file read-only in > Windows, then run "fossil ui". > So it is. You can also repro by running a plain old "sqlite3.exe" command-line shell. Start the shell with no argument, then

Re: [fossil-users] Continued issues with read-only repository

Nothing happens. By which I mean Fossil refuses to start, saying it sees no xyzzy here. So, twice as much happens. Therefore it is honoring my VFS change, and picking win32-none is not the solution to my problem. To reproduce, all that's needed is to set the repository file read-only in

Re: [fossil-users] Continued issues with read-only repository

On 9/21/17, Andy Goth wrote: > I added "set FOSSIL_VFS=win32-none" to my documentation viewer batch file. > This had no apparent effect. Is there another value I can give it that will > have a more dramatic effect to confirm it's being seen by Fossil? set

Re: [fossil-users] Continued issues with read-only repository

I added "set FOSSIL_VFS=win32-none" to my documentation viewer batch file. This had no apparent effect. Is there another value I can give it that will have a more dramatic effect to confirm it's being seen by Fossil? On Sep 21, 2017 8:08 AM, "Richard Hipp" wrote: > On 9/20/17,

Re: [fossil-users] Continued issues with read-only repository

On 9/20/17, Andy Goth wrote: > I'm fine in Linux working from a loopback-mounted ISO9660 disc image, > but in Windows 8.1 doing the same nets me the following: > > SQLITE_NOTE: delayed 1375ms for lock/sharing conflict at line 43312 > SQLITE_CANTOPEN: os_win.c:43319:(5)

Re: [fossil-users] Continued issues with read-only repository

Okay cool, I'll tell the Air Force that's what they need to do. On Thu, Sep 21, 2017 at 7:13 AM, Roy Keene wrote: > Quit using Windows ? > > > On Wed, 20 Sep 2017, Andy Goth wrote: > > I'm fine in Linux working from a loopback-mounted ISO9660 disc image, >> but in Windows 8.1

Re: [fossil-users] Continued issues with read-only repository

Quit using Windows ? On Wed, 20 Sep 2017, Andy Goth wrote: I'm fine in Linux working from a loopback-mounted ISO9660 disc image, but in Windows 8.1 doing the same nets me the following: SQLITE_NOTE: delayed 1375ms for lock/sharing conflict at line 43312 SQLITE_CANTOPEN: os_win.c:43319:(5)