Subversion in the classroom

[Greg Wilson <Gr...@baltimore.com>]

Hi, all.  Hope you don't mind yet another message out of
the blue, but I've been teaching a second-year course at
the University of Toronto this summer [1], in which student
assignments have been managed through CVS (rather than by
mailing students a tarball of the starting point, and having
them mail back another tarball when they're done, which is
how it's normally run).  CVS has worked pretty well for us,
but there have been a couple of problems, one of which is
looking pretty gnarly.  I'm therefore looking at switching
over to SVN in January (don't think there's time to make
and test the change for September, which is the next run
of the course).  If you have time, I'd be grateful if you
could let me know whether SVN is likely to run into the
same swamp.

The basic problem is file permissions.  We have 75 students
in the course this summer, and will be scaling up to approx.
350 in the fall.  Each student gets her/his own repository.
These are hosted on Linux or Solaris, depending on which
campus they're on.  We make the students the owners of their
repository directories, but set the group to a group that
contains the course instructors and TAs.  That way, students
can't see each other's work, but the instructors and TAs can
see everything.  As long as no-one messes up sticky bits,
this does what we need.

Things start to fail when we put students into teams of two
or three (there are some pair programming assignments in the
course).  The idea was to create one group for each team,
put the students in the team into the group, and make the
instructors and TAs members of each of those groups.  However,
both Linux (recent RedHat releases) and Solaris put a sharp
upper bound on the number of groups someone can actually belong
to.  The admin tools will let you put someone in two hundred
groups, but a running process only appears to belong to at
most 16 (on RedHat) or 32 (on Solaris).  Sure enougn, when
we grep the Linux source, NGROUPS_MAX is 16.  (Can't grep
the Solaris source... ;-)  This means that the instructors
and TAs cannot get at most of the students' repositories.

OK, so what about ACLs?  Works on Solaris, but RedHat has
decided not to put them into near-future releases, because
they're not stable enough.  And CVS's own auth mechanisms
are insecure (cleartext passwords over the wire --- br...).

So, would SVN help us here?  Or does it also rely on the
underlying file system for access control, in which case
we're back to where we are now...

Thanks,
Greg Wilson

[1] http://www.cs.utoronto.ca/~csc207h


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being 
passed on.
 
This footnote confirms that this email message has been swept for Content Security threats, including
computer viruses.

http://www.baltimore.com

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

Re: Subversion in the classroom

[anton <an...@nezzwerk.com>]

Ben Collins-Sussman wrote:

> Greg Wilson <Gr...@baltimore.com> writes:
> 
> 
>>So, would SVN help us here?  Or does it also rely on the
>>underlying file system for access control, in which case
>>we're back to where we are now...
> 
> 
> If you use apache and *only* apache to access repositories, you can
> circumvent all unix permissions issues:
> 
> Use apache as your svn server for all your repositories.  From a unix
> permissions point-of-view, the apache process "owns" all the files in
> every repository.
> 
> Then create apache accounts for each student.  (No need for unix
> acounts.)
> 
> Then use mod_authz_svn access files to define groups of students, and
> exactly which repositories they are allowed to access.
> 
> Voila, exactly what you want.
> 
> 

or use any of the available apache mods for authentication/authorization 
against ldap, database, etc - once again, completely removed from the OS 
auth mechanisms.
-- 
anton


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion in the classroom

[Ben Collins-Sussman <su...@collab.net>]

Greg Wilson <Gr...@baltimore.com> writes:

> So, would SVN help us here?  Or does it also rely on the
> underlying file system for access control, in which case
> we're back to where we are now...

If you use apache and *only* apache to access repositories, you can
circumvent all unix permissions issues:

Use apache as your svn server for all your repositories.  From a unix
permissions point-of-view, the apache process "owns" all the files in
every repository.

Then create apache accounts for each student.  (No need for unix
acounts.)

Then use mod_authz_svn access files to define groups of students, and
exactly which repositories they are allowed to access.

Voila, exactly what you want.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org