On Tue, Apr 11, 2017 at 10:36 AM, Thomas <tho...@dateiliste.com> wrote: > On 2017-04-11 05:22, Scott Robison wrote: >> >> Perhaps it should be documented, but I don't think it is a bug. It is >> the software doing the job it was originally told to do (track versions >> of a file) instead of doing the job it was subsequently told to do >> (ignore untracked files with a given glob). >> >> For example, I have licensed libraries in the past that are shipped as >> obj files. They need to be tracked, even though most obj files don't. >> This model allows you to add certain obj files which will be tracked >> while ignoring all others. > > > You're a good salesman. ;-) > > Do you work for Microsoft by any chance? You're trying to sell a design flaw > or bug as a feature. ;-)
No, I try to explain why what you see isn't a design flaw, and apparently fail. But I'll keep trying! > Source code management != backup Never said it was. Keeping an obj file in a repo because there is no corresponding source from which to build it is valuable so that other people can get access to all the build artifacts required. > I would like to emphasise that --ignore (or .fossil-settings\ignore-glob) is > an _explicit_ command, clearly stating the user's desire for exlusion of > these files, following the documentation. > Silently ignoring this wish can't be the correct process. No, it is an explicit command clearly stating the user's desire for exclusion of these files *that are not already under source control*. The fact that the user does not remember or did not realize they issues conflicting commands does not mean that fossil should suddenly stop tracking the file, or so it seems to me. If a file was previously added to a repository (indicating a desire to keep track of modifications to the file), that is more important than ignoring the file. > A switch that doesn't work is either a huge design flaw or a bug. A --ignore > switch that doesn't ignore is a huge security bug (and a trap) too. Ignoring does work as desired. It only applies to files that match the pattern that are not already in source control. > What would I need a --ignore switch for when I got to delete the files first > manually anyway? That's completely contrary to its purpose, isn't it? The > reason why I'm using --ignore is because I _don't want_ to delete these > files. Going back to my examples from yesterday: I had an ignore-glob of *.a. I ran addremove and it ignored the a.a file, but not the b.b file. If I ran add a.a, it warned me that it was in the ignore pattern, but allowed me to add it anyway. Today I went back to that example repository and created a file c.a and ran addremove. It ignored c.a because I had not added it previously. If I delete the ignore-glob file and use the --ignore switch with '*.a' it behaves identically. > Every virus scanner, backup software, mirroring software, every other source > code revision management, webserver, and god knows what else, follows its > exclusion rules. --ignore is not a "remove existing files from the repository rule" switch. It is an "ignore unmanaged files that match a pattern" switch. > Sorry, I can't see any logic behind this, apart from that this bug or design > issue may have slipped in accidentally and now no one's willing to fix it, > but trying to defend and advertise it as a feature... ;) Just because you can't see it doesn't mean it isn't there. It is an intentional design to allow the ignoring of unmanaged files. > File add.c on line 672 says: > /* step 1: > ** Populate the temp table "sfile" with the names of all unmanaged > ** files currently in the check-out, except for files that match the > ** --ignore or ignore-glob patterns and dot-files. Then add all of > ** the files in the sfile temp table to the set of managed files. > */ > According to this, it seems it's a design flaw. The key words are at the end of line 673 and the beginning of line 674: "unmanaged files". By definition, a managed file (one that has been previously added to the repository) is not an unmanaged file. Thus it is working as described. The only thing I can think at this point is that you believe that if *any* file matching a glob pattern is in the repository, all files matching that same glob pattern will be added to the repository despite the glob pattern. This is not how my current version of fossil (downloaded from the fossil-scm site a few days ago) behaves. Only files already in the repository (managed files) with changes will be committed. -- Scott Robison _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
