Re: [fossil-users] Limiting cruft in my repos

[Warren Young]

On May 10, 2017, at 6:40 PM, David Mason  wrote:
> 
> On 10 May 2017 at 17:05, Artur Shepilko  wrote:
> 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.

[snip]

> ...covers 4 very different programming languages in 12 weeks.  There is no 
> time for nuance in SCM details.

Do you not mark down homework for bad code formatting, poor variable names, 
missed corner cases, poor commenting, etc.?

I don’t see “lazy checkins” as any different.

And mark them down for poor-quality checkin comments while you’re at it.

Yes, this means lots of ways to mark down, so that no student is expected to 
score 100%.  That problem also has a solution: curve grading.  I once took a 
class where the students achieving an “A” grade might get 2/3 the answers on a 
test right.

> ...making SCMs and TDD intuitive concepts for all humans...

"The only intuitive interface is the nipple. Everything else is learned.” 

— Bruce Tognazzini
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[Ross Berteig]

On 5/10/2017 1:12 PM, Tony Papadimitriou wrote:

So, ignore ‘makefile’?
*From:* Ross Berteig 
# ignore files without at least one dot somewhere in their name
!*.*


Yup. It would do that. And README, LICENSE, CHANGELOG.  Not without its 
problems. But ignore-glob is just a suggestion. YOu can still say fossil 
add makefile and it will add it. It just won't add it by default when 
you say fossil addremove.


--

Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[David Mason]

On 10 May 2017 at 17:05, Artur Shepilko  wrote:

> 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.
>

While I might agree, and the top x% of the students would get that, x is
far smaller than any of us would like (probably 30% or less).  I further
can't afford a week of lectures to nail down the concept of SCMs.  The
largest course that I use fossil for has 160 students - with a wide range
of competencies - and covers 4 very different programming languages in 12
weeks.  There is no time for nuance in SCM details.

Unfortunately.

(If someone made me god, or gave me a magic wand, I would make the world
very different in many ways... including making SCMs and TDD intuitive
concepts for all humans, or at least all who would become programmers. :-)

../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[Artur Shepilko]

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  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

Re: [fossil-users] Limiting cruft in my repos

[Tony Papadimitriou]

So, ignore ‘makefile’?

From: Ross Berteig 
# ignore files without at least one dot somewhere in their name
!*.*
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[Ross Berteig]

On 5/10/2017 7:08 AM, David Mason wrote:
I generate the initial fossil for them. The problem is that I don't 
control, e.g. executable names, so if they have foo.c and say `make 
foo` they will have foo.o which I can match, but also foo which I 
can't (because they might call it foox.c - and hence foox - instead).


Because I generate the initial fossil the `:::BINARY:::` pattern in 
the ignore-glob file is viable, as would be a `:::SizeOver:::10` 
pattern.


Here is an example of where Windows is slightly better off. By clearly 
designating a binary executable as `.exe`, you can put that in the 
ignore-glob and be confident.


Unfortunately, file globs are not regexps so you can't ignore any file 
without a dot in its name. But you could if we included a feature that 
Git has, allowing ! at the front of a glob to invert the match. If we 
had that (and comment lines in glob files), I think this might work:


# ignore obvious build targets
*.o *.d *.a *.so
# ignore files without at least one dot somewhere in their name
!*.*
# and for Windows
*.obj *.lib *.dll *.exe

But that will treat "lesson.one/foo" as allowed, not ignored as you 
might have preferred.


Having a way to use SQLite's REGEX instead of GLOB for filename matching 
on a case-by-case basis would also be a solution. It would allow writing 
a regex that excludes "lesson.one/foo", at least. Not sure what the best 
notation to propose for that would be, or if the REGEX operator is 
enabled in fossil's loaded SQLite.


--

Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[David Mason]

I generate the initial fossil for them. The problem is that I don't
control, e.g. executable names, so if they have foo.c and say `make foo`
they will have foo.o which I can match, but also foo which I can't (because
they might call it foox.c - and hence foox - instead).

Because I generate the initial fossil the `:::BINARY:::` pattern in the
ignore-glob file is viable, as would be a `:::SizeOver:::10` pattern.

I'm mostly not worried about them intentionally or maliciously creating
cruft, but rather accidentally and carelessly.

../Dave

On 10 May 2017 at 09:50, Andy Bradford  wrote:

> Thus said David Mason on Wed, 10 May 2017 01:07:22 -0400:
>
> > 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!
>
> Do students  generate their own Fossil,  or is the Fossil  generated for
> them? If  it is generated for  them, why not just  commit an ignore-glob
> that covers the kinds of large files  they are likely to generate to the
> .fossil-settings directory?
>
> Andy
> --
> TAI64 timestamp: 400059131ac8
>
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[David Mason]

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  wrote:

> On 5/10/17, David Mason  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

Re: [fossil-users] Limiting cruft in my repos

[Andy Bradford]

Thus said David Mason on Wed, 10 May 2017 01:07:22 -0400:

> 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!

Do students  generate their own Fossil,  or is the Fossil  generated for
them? If  it is generated for  them, why not just  commit an ignore-glob
that covers the kinds of large files  they are likely to generate to the
.fossil-settings directory?

Andy
-- 
TAI64 timestamp: 400059131ac8


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Limiting cruft in my repos

[Richard Hipp]

On 5/10/17, David Mason  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