On 12/21/13, David Given wrote:
> The big gotcha, of course, is scripts, which typically perform several
> changes on similar files in very rapid succession --- that's precisely
> how I found this myself.
In this case, the script would (should) know which files it had changed so
could force the c
David Given wrote:
The big gotcha, of course, is scripts, which typically perform several
changes on similar files in very rapid succession --- that's precisely
how I found this myself. I find myself very uneasy about having this
defaulting to "on". I have no objection to having the option ther
I'd agree with David, here. By the time most people have "large"
repositories, they can figure out if the optimization is worth it to
them. But the default should always be safety!
../Dave
On 21 December 2013 19:47, David Given wrote:
> On 21/12/13 22:00, Richard Hipp wrote:
> [...]
>> For a l
On 21/12/13 22:00, Richard Hipp wrote:
[...]
> For a large repo with many files, mtime-changes "off" means that many
> operations are slow, because running SHA1 hashes on thousands of files
> takes significant time. Hence mtime-changes is "off" by default. Normally
> this does not cause problems,
On Sat, Dec 21, 2013 at 09:34:45PM +, David Given wrote:
> On 21/12/13 21:24, Joerg Sonnenberger wrote:
> [...]
> > Yes, it certainly uses mtime by default to skip the much more expensive
> > hashing step. You can disable that from the settings.
>
> You mean it's *supposed* not to do the SHA1
On Sat, Dec 21, 2013 at 4:34 PM, David Given wrote:
> On 21/12/13 21:24, Joerg Sonnenberger wrote:
> [...]
> > Yes, it certainly uses mtime by default to skip the much more expensive
> > hashing step. You can disable that from the settings.
>
> You mean it's *supposed* not to do the SHA1 hash by
On 21/12/13 21:24, Joerg Sonnenberger wrote:
[...]
> Yes, it certainly uses mtime by default to skip the much more expensive
> hashing step. You can disable that from the settings.
You mean it's *supposed* not to do the SHA1 hash by default? Isn't this
horribly unsafe (because you'll miss changes,
On Sat, Dec 21, 2013 at 09:21:25PM +, David Given wrote:
> I have found a rather unpleasant-looking bug where if a file's content
> changes too quickly, and its size does not change, it's not considered
> to have changed. It smells as if Fossil is using a combination of the
> file length and ti
(Why yes, I am doing something moderately evil with Fossil...)
I have found a rather unpleasant-looking bug where if a file's content
changes too quickly, and its size does not change, it's not considered
to have changed. It smells as if Fossil is using a combination of the
file length and timesta
9 matches
Mail list logo
