Not sure about the objectives the students are learning in this
course,  but if it in any way relates to programming, recognizing as
to what to keep under version control is a reasonable objective on its
own. There could be valid reasons to keeping executables and other
build artifacts versioned, but convenience of a "lazy-dot-add",
followed by "blind-commit" should not be one :)

I guess, some incentives for not keeping such binaries committed may
as well solve this for the course.

Additionally, out-of-source build may as well be a heplful practice to
follow. This way all build artifacts automatically would be out of the
source-repo or could be excluded in the .ignore-glob setting of the
repo template. Perhaps enforce this in the make file.


On Wed, May 10, 2017 at 12:07 AM, 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?
>
> Thanks  ../Dave
>
> _______________________________________________
> 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

Reply via email to