Yes, that would work. A flag to reject binary files could work too, for all the .o and .beam files that are small but annoying. I know that wouldn't work perfectly as the binary detection is heuristic, but would be very convenient. Actually a flag that caused `fossil add` and `fossil addremove` to treat binary files as if they were in the ignore-glob would be perfect because you could override it with `--force` when the heuristic was wrong. Alternately a special pattern in ignore-glob like `:::BINARY:::` would work.
It would also be convenient if these were exported configuration so when they first clone the repo their local repo gets the configuration. ../Dave On 10 May 2017 at 07:11, Richard Hipp <d...@sqlite.org> wrote: > On 5/10/17, David Mason <dma...@ryerson.ca> wrote: > > I've described before how I use fossil to manage student assignment > > submissions in courses I teach. > > > > A perennial problem is that the students commit binary executables, .o > > files, and the like. Theses change every build so I have dozens of > versions > > of potentially large files in the student repos. Disk is cheap, but when > > you have hundreds of students committing multiple versions of > > multi-megabyte, it adds up. If the students were very disciplined, they > > would assiduously edit ignore-glob to prevent this. But if there is one > > thing that students (en-mass) are not, it's disciplined! > > > > So I need something on the server side that will block large and/or > binary > > files from being saved (like an implicit shun). > > > > Any ideas? > > > > Crazy idea: Maybe we could add an option to the server configuration > so that it rejects all files larger than a preset size - say 1MB. > Source files would always be less than 1MB. (Well, almost always - > sqlite3.c is 7.1MB. But student-written source files are less than > 1MB.) The rejection size threshold would be configurable, of course, > and would default to infinity (and thus be turned off by default). > Would something like that work for you? > > -- > 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 >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
