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 ;-)
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 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. ;)
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 ;-)
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?
I actually expected that some defaults would have been applied already
but that's not the case, which is of course good. All files and folders
got committed, apart from empty directories. It turned out Fossil
doesn't know about folders (according to the documentation), hence I
just created an empty file in each empty folder.
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.
Yepp, that's what we figured out now. ;)
Since the software is a single executable it comes without any ignore
settings, hence it applies to precisely how many files after the first
commit? Correct: Precisely _zero_! ;)
So, --ignore or .fossil-settings\ignore-glob have _no_ function at all
at first. That's not a lot for a command-line switch that's supposed to
ignore 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.
I agree that I would have seen a warning with add. However, with
thousands of files in a folder, that command is not very efficient
compared to addremove.
--ignore is not a "remove existing files from the repository rule"
switch. It is an "ignore unmanaged files that match a pattern" switch.
I wasn't and I am not expecting it to remove existing files from the
repository. I'd expect it to simply ignore these files for the current
commit.
Again, that switch is completely useless after a first commit with all
files. It does absolutely nothing. I find it a bit strange that I'm
supposed to be the first one to notice this. Fossil is not just a couple
of weeks old.
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.
And since all files are managed after the first addremove and commit,
and every consecutive invocation(s), there's no unmanaged files left,
rendering the switch's function to no function at all.
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.
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. ;-)
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
