On Tue, Apr 11, 2017 at 3:04 PM, Thomas <tho...@dateiliste.com> wrote: > On 2017-04-11 19:34, Scott Robison wrote: >> >> No, I try to explain why what you see isn't a design flaw, and >> apparently fail. But I'll keep trying! > > > Since I've never heard of any software that would not ignore files it is > told to ignore you're going to have a hard time to convince me ;-)
I'll concede that the thoughts of the fossil devs heavily influence how options work and what they think they should do. I would be surprised if a file I told the system to track was not because of some other set of files I wanted to ignore. >>> 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. > > > Keeping hundreds of megabytes of SQLite Visual Studio Intellisense databases > is not something required to build the software. It is also not something > desirable to delete on the originating machine just to satisfy the odd > behaviour of the SCM. To be fair, Fossil does a very good job in only > storing the compressed differences. Although the files are quite big, the > repository only grew by about 10 or 12 MiB with each commit. I never suggested anyone would want to track megabytes of such files. > I believe that Fossil users are software developers and know what happens to > object files they exclude. I believe they're smart enough to either rename > object files they need in the repository if they set up exclusion filters, > or that they would set up appropriate filters. They'd find out as soon as > they test it, and they can find out with "fossil ui". In my opinion this is > a very weak excuse. ;) Or maybe they're smart enough to use the software as designed. #zing #sorry #lowblow I kid, really. I understand most of your points. There is definitely room for confusion. >>> 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*. > > > That's not what the documentation says ;-) To be fair, the documentation doesn't really say either way. One would need a standards body to write documentation that has no issues. And even then there are still issues because someone comes along later and disagrees with what a set of words should be defined to mean. Unless of course you're talking about the documentation in the source code fragment you quoted earlier, in which case it did say that it was only building a list of unmanaged files. >> 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. > > > Isn't it a natural thing that the first step everyone does when trying out a > revision management system is commit everything they got as they haven't set > up any exclusions at that time? Not for me. I run changes and extras commands almost every time I run addremove just to be sure there aren't any surprises, and if I find any, I will update glob patterns as needed. > I can't imagine that this is really its intended function. If it really is, > then this should be marked in triple-bold and red with green and pink > stripes in the docs. One of my earliest replies was a concession that documentation may need to be updated. >>> 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. > > That's from the source code of add.c. I don't think many people skim through > the source code when there's other accompanying documentation provided. ;-) But you did. :) I agree it is not the place most users will go for documentation. But it is awfully good evidence that it is working as designed and intended. CHECKMATE! :) -- Scott Robison _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
