[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Beginner admin question: organizing repository for student projects

From: David Weintraub <qazwart_at_gmail.com>
Date: Mon, 22 Feb 2010 16:17:39 -0500

First of all, I'd like to congratulate you about getting your students
use to version control. When I went to college, I was taught how to
program, but never learned about the various tools used in the
process. We did C programming and never use Makefiles. My son learned
Java, but never used Ant or Maven. And, of course, there was no
discussion at all about version control.

I'm going to make a slight recommendation. Even though this is a
Subversion list, I am a Subversion admin, I like Subversion, and I've
posted before why I think decentralized version control systems like
Git are not the best way to do every project, I would recommend that
you use a decentralized version control system like Git in your
particular case.

The reasons are quite simple: You probably have a lot to do in your
job, and you don't want to become a full time Subversion
administrator. If you have a small CS department, you'll have maybe
four instructors and 100 students. Every year, if all goes according
to plan, 1/4 of those students graduate, and another 1/4 enter as
freshmen. Just looking at the straight and narrow: You have 100 people
you have to track in your Subversion repository. And, every year, 25
of them leave and another 25 come in.

Plus, you are talking about a dozen classes. That's dozen classes will
have several projects, and several students in each project. However,
some of those students will have multiple classes, and have particular
projects in each of those classes they have to have permission on.
You'll be spending 40 hours each week simply adding new projects and
permissions. And, this is for just a very small CS department.

A decentralized version control system can make your life much
simpler. You create a repository, and in your repository, you'll only
accept changes from the instructors. In a decentralized system, the
instructors will create a sub-repository from your repository, and
they'll handle the student permissioning in their sub-repositories.

If a student checks in code to the instructor's repository and the
instructor takes the change and that instructor submits those changes
to your repository, you can take those changes too. Thus, the
student's work is now in your repository. However, if that student
tried to submit those changes directly to you, you'd reject them
because you will only take changes from your instructors. If a student
wants to make changes, they'll have to submit them to the instructor's
repository first.

Most of the acceptance and rejection of changes can even be automated,
so your time and effort on running your version control system is
minimal.

Distributed version control systems have a lot of issues: They
encourage developers to work in their own little world and present
last minute changes. Security can be an issue since developers are
free to share their "repositories" without the central owners knowing
what is going on. Distributed version control systems simply are a big
pain in small environments and in development that has to be
centralized (such as corporate development).

However, the big advantage of a distributed system is that you can
distribute the workload and issues down the line. You no longer have
to know what project each and every student is working on. Now, your
instructors can set that up.

On Mon, Feb 22, 2010 at 2:37 PM, Stephen Bloch <bloch_at_adelphi.edu> wrote:
> I want to get my undergraduate students in the habit of using svn, both for
> individual projects and for group projects.  I'd like to be able to create
> projects that belong to a whole class, and to an arbitrary subset of
> students, and to an individual student. And I'd like to be able to set up
> the repository once and for all so that I don't have to reorganize it every
> semester.  The usual "trunk/branches/tags" organization didn't seem
> appropriate, at least at the top level.  Any advice from people who have set
> up a system like this?
>
> I was thinking of something like this
> users
>        joe
>        bob
>        mary
>        etc.
> classes
>        cs160
>        cs171
>                thisproject
>                thatproject
>        cs172
>                theotherproject
>                thefourthproject
>        etc.
>
> Each student would have a directory within users, with full access to that
> directory.
> Each student would also have read access to the directory for each class the
> student was in, and write access to the directories for projects that the
> student is involved in.  The instructor of each class would have write
> access to the directory for that class.
>
> Is this really stupid?  Am I "not getting" SVN?
>
>
> Stephen Bloch
> sbloch_at_adelphi.edu
>
>

-- 
David Weintraub
qazwart_at_gmail.com
Received on 2010-02-22 22:18:13 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.