On 2/11/15, Zoltán Kócsi <zol...@bendor.com.au> wrote:
> I use fossil version 1.29
>
> I have a project where there's a file, simple text.
> That file is manipulated by a tool. The tool always keeps the previous
> version of the file, renaming it.
>
> So, we have a file 'foo' and 'foo.bak' and whenever foo changes, the
> old version of foo is renamed to foo.bak (and the old foo.bak gets
> deleted).
>
> The actual repository is on a remote machine and auto-pull and
> auto-push are both on, so update and commit both access the remote.
>
> I started with a perfectly synchronised state, everything everywhere was
> the latest, the checkout, the local fossil repo and the remote all
> matching.
>
> I then ran the tool, so I got a new foo and foo.bak. Then came the
> interesting bit:
>
> When I ran
>
> fossil status
Fossil uses file mtimes and sizes to help it detect changes. When
your tool moves foo to foo.bak, this changes neither the mtime or the
size. So Fossil fails to detect the change, by default.
You can modify the behavior of Fossil to cause it to compare SHA1
hashes on all files by doing:
fossil setting mtime-changes off
This will make commands like "fossil status" run slower on really big
repositories. But for reasonably sized repositories, it shouldn't
make a noticable performance difference.
You can also run
fossil status --sha1sum
to use hashing for a single instance of the command, without changing
the default setting.
>
> fossil told me that 'foo' was edited, but it kept silent about foo.bak.
>
> Then I told it
>
> fossil commit -m "Some message"
>
> then it complained that foo.bak on disk was different from foo.bak in
> the repository and told me two hash-es and then refused to commit. In
> addition, in the check-out directory it created a file called
> 'file-<HASH>' where <HASH> is a hash value in hex.
>
> If I then do a
>
> fossil rm foo.bak
> fossil add foo.bak
>
> and try co commit, the same thing happens, except that a new file with
> 'file-<HASH>' is created, with a different hash value.
>
> I could not commit foo until I settled for
>
> fossil rm foo.bak
>
> and gave up on keeping track of the backup file.
>
> Is there a rational explanation for the above or should I start
> worrying about the integrity of the repo - that would me a major
> disaster for the project :-(
>
> Thanks,
>
> Zoltan
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
