On 2017-09-07 00:48, Richard Hipp wrote:
On 9/6/17, Thomas <tho...@dateiliste.com> wrote:
If I unshun
a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a now the
next one to check in (run the check-in script) would cause all the other
empty files to be distributed to everyone else, wouldn't they?
Why are those not removed, by the way? They got the same SHA3 key.
A file name and a file's content are distinct and separate objects.
The SHUN mechanism removes file content. The file names are entries
in the manifest file for a check-in and are unaffected by shunning.
Shunning a zero-length file does not hide any information from
anybody. Everybody can still clearly see the name of the file in the
manifest, and its hash, and from the hash they can deduce that the
file is empty, even if that file has been shunned.
Shunning is designed to remove content from the repository, not the
filename of the content. Shunning is intended, for example, to remove
a file of passwords that you check-in accidently. After shunning,
everybody can still see that you accidentally checked in the password
file, they just cannot see the content of the password file.
You seem to be wanting that the shun remove the filename too, so that
nobody can see that you even checked in the file mistakenly. But that
is not possible without shunning the entire check-in.
Thanks for this detailed reply. However, I'm still confused.
No, that's not what I want. There's no reason for the files to be hidden
in any way.
To be honest, the current behaviour is not an issue for us anymore
either. We solved it within the script that looks for the empty file
that keeps being removed.
It's just that I would like to understand what's happening and why.
We got two types of empty files in our project.
One type is used as a flag, more or less privately for each contributor.
Their existence is no secret, just a personal preference. A script
checks for its existence. If these empty files don't exist, certain
scripts spit out several warning messages (= the default). Each
contributor can suppress these warning messages by creating an empty
file with a particular name in the folders in question. After that, they
won't see these warnings anymore. These files are (or can be) scattered
all over the project's folder tree.
The other type of empty files (actually, just one single file) is used
for a test case to check how one part of the project gracefully handles
an empty file. So, this file is actually not created by every
contributor individually according to their preferences but part of the
checkout.
Every time one of the contributors checks in (= runs our checkin script)
fossil addremove --dotfiles
fossil update --force-missing
fossil configuration pull shun
fossil commit --allow-empty --allow-conflict --hash
the file that is part of the test suite is removed here.
The other empty files are not removed. Why? What could cause this
behaviour? I got several of those empty files that suppress the warning
messages as explained above.
The SHA3 hash for an empty file is in the shun list. What is going to
happen if I remove this entry? Would all those "suppress warning" files
be distributed among the team, i.e. would I with my next checkin turn
off all warning messages for everyone else?
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
