From users-return-1153-daniel=haxx.se@subversion.apache.org Mon Feb 22 22:18:13 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o1MLICK6032493 for ; Mon, 22 Feb 2010 22:18:13 +0100 Received: (qmail 85812 invoked by uid 500); 22 Feb 2010 21:18:07 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 85804 invoked by uid 99); 22 Feb 2010 21:18:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Feb 2010 21:18:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of qazwart@gmail.com designates 209.85.218.214 as permitted sender) Received: from [209.85.218.214] (HELO mail-bw0-f214.google.com) (209.85.218.214) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Feb 2010 21:18:00 +0000 Received: by bwz6 with SMTP id 6so2480470bwz.36 for ; Mon, 22 Feb 2010 13:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZREOACidYJ7naiZUIxp2osJi5bbYQTTBA+bdM7LVsAY=; b=c11vdlMIgBjM3hVexGHRGbGfT9GTF88vON8SFAFKUJtAjBQHyu0Z6XHsgFsIMIhncV XCzmq6seDRAV+Fo5zbk9Gjb2v3aN4x0+/1PJ5EGRSafFVNqrnzl/NWZ2muZhTdED70xX WdOEQvc5n2Qwo9DupU7arDKCLy60P7FE8sINM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=guCTGXgsjPRIPncjl+74WcbpzaJQMHRymWf+CZ6YQWQGQB3WFR29dBvSVJLz5Ni18H pZGcm95WWtEu+V0JFS4//zaV7EL2pmonbJg5z6lLM6T6iLOFG7FBM3axahhc0cVL7jlY nQHsRh/28rs2Hh2Z5S5nX4kjxoRE3TJBpLqrc= MIME-Version: 1.0 Received: by 10.204.32.15 with SMTP id a15mr3190110bkd.142.1266873459198; Mon, 22 Feb 2010 13:17:39 -0800 (PST) In-Reply-To: <691D6C29-D3D5-4F0A-849D-D7B0EF49508E@adelphi.edu> References: <691D6C29-D3D5-4F0A-849D-D7B0EF49508E@adelphi.edu> Date: Mon, 22 Feb 2010 16:17:39 -0500 Message-ID: Subject: Re: Beginner admin question: organizing repository for student projects From: David Weintraub To: Stephen Bloch Cc: users@subversion.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wrote: > I want to get my undergraduate students in the habit of using svn, both f= or > individual projects and for group projects. =A0I'd like to be able to cre= ate > 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 eve= ry > semester. =A0The usual "trunk/branches/tags" organization didn't seem > appropriate, at least at the top level. =A0Any advice from people who hav= e set > up a system like this? > > I was thinking of something like this > users > =A0 =A0 =A0 =A0joe > =A0 =A0 =A0 =A0bob > =A0 =A0 =A0 =A0mary > =A0 =A0 =A0 =A0etc. > classes > =A0 =A0 =A0 =A0cs160 > =A0 =A0 =A0 =A0cs171 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thisproject > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thatproject > =A0 =A0 =A0 =A0cs172 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0theotherproject > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thefourthproject > =A0 =A0 =A0 =A0etc. > > Each student would have a directory within users, with full access to tha= t > 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. =A0The instructor of each class would have write > access to the directory for that class. > > Is this really stupid? =A0Am I "not getting" SVN? > > > Stephen Bloch > sbloch@adelphi.edu > > --=20 David Weintraub qazwart@gmail.com