Archive for May, 2010
I have been working on ticket #537 again. There is still this old review request this sitting around (see http://review.markusproject.org/r/327/). The idea was that MarkUs should use a student’s username as the name of the Subversion repository created. This makes remembering student’s repository names easier. As simple as it sounded initially, there are some delicate corner cases to deal with.
- MarkUs allows instructors to reuse groups from previous assignments. Motivation for this feature was as follows. Students work on assignments alone throughout the term. In this case there is no need for students to form groups for each assignment. Students work alone anyway and once they’ve logged in a repository will be created for them (alternatively, an instructor has groups already set up so that students have repositories right away). The idea is to have students commit their code into these repositories created by MarkUs. It would be overkill, though, to create a brand new repository (and groups) for each assignment. So there is the possibility for instructors to set things up in a way that repositories are created once. But since the repositories already exist for later assignments we need a way to link those existing repositories with new groups for a new assignment. So one way is to use the “Use another assignment’s groups” feature. So far so good. But what if an instructor wants to have single student groups for A1 (allowing Subversion command line commits only) but wants to allow students to submit via MarkUs web interface for a small lab exercise? Assume for the lab exercise they would be allowed to form groups of two. Problem: If we would allow cloning groups forward for assignments for which web submissions are allowed, MarkUs could potentially link to the repository of A1. So things could end up in a repository called “c5anthei” and student c5bloche and c5anthei would be able to submit to it via the web interface. This seems a bit awkward, since the idea is to have repositories named after the student’s username only when it’s a single student assignment and it’s a command line commit only assignment. Solution: Cloning groupings forward for assignments won’t be allowed for assignments which enable MarkUs’ web submission interface.
- Using student’s usernames as the repository name opens up the possibility of repository collisions. I.e. MarkUs could end up trying to create a repository twice with the very same name (just imagine an instructor uploading the very same CSV groups file twice). Solution: This will happen for single student and non-web-submit assignments only. If a collision occurs the repository already exists, but that’s everything the CSV upload tries to achieve (apart from creating the groupings in MarkUs). But since MarkUs won’t create a repository if it already exists, this is a minor concern. This cannot happen for web submit assignments, because in this case a unique name for the repository will be generated. If a repository collision happens during a CSV upload, MarkUs will notify the instructor about it.
- MarkUs “recycles” groups. MarkUs internally knows about groupings and groups. A grouping is basically a snapshot of students and their memberships in groups for a particular assignment. In fact, when you create a “Group” (in the usual sense) using MarkUs’ web interface a grouping will be created. If a group object does not exist yet, it will be created too. This behaviour might be different for the next grouping, because a group object with the required name might already exist in the database. I.e. if a group with a particular name already exists, MarkUs will try to reuse it. Thus, it’s theoretically possible to create a group “Beta 10” for assignment 1 (say for A1 students work alone and have to commit via command line client). Then for A2, say, the instructor wants to create group “Beta 10” again, now allowing web interface submits and groups > 1 members. In that case MarkUs will find group “Beta 10” in the database and will try to use this group instead of creating a brand new object. This is a problem if an instructor would pick a group name which is equal to a student’s username. We’d end up in a similar situation as described in (1). Solution: I think, the most clean solution is to require instructors to use the user’s username as the group name (and those groups can have one group member at most). Otherwise, an autogenerated repository name will be used.
Those three corner cases are the ones I could think of so far. I’m not sure if we are still missing some. Let me know if there is a problem with my reasoning or if there are other cases I haven’t thought of, yet. Thanks! I’ll post an updated review shortly.
Edit: Considering that the repository name will be set in this special way for one member only groups, some of those cases might occur very rarely (if at all). Solution to (3) also means that it should be impossible to produce repository collisions. What do you think?