MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for the ‘repository’ tag

Repository Names Generated by MarkUs

with 2 comments

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.

  1. 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.
  2. 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.
  3. 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?

Written by Severin

May 1st, 2010 at 8:06 pm

Introducing MarkUs 0.6.3!

with one comment

The MarkUs Team is proud to introduce 0.6.3!

Changes for MarkUs 0.6.3:

  • Added rake task to automatically regenerate svn_authz in the event of corruption (rake markus:generate_svn_authz)
  • MarkUs now ensures student read/write permissions on repositories after cloning groups

Get 0.6.3 while it’s hot! Or click here to patch your MarkUs instance up.

We’re on the final stretch, and MarkUs 0.7 is looking to be pretty awesome!  Keep your eyes peeled!

Written by m_conley

March 20th, 2010 at 5:57 pm

Using Subversion for File Storage

without comments

Over the past few days, the team has been talking about how we eventually want to use Subversion as the file storage backend for the work that students submit through OLM.

Here’s what we ended up deciding:  we’re going to build a generic Repository class, and have three different implementations:  File System, Memory, and Subversion.

Each Repository will return Revision objects, and each revision will have File’s and (eventually) Directories.

So, how would this thing work?  Say I want to get all files from the root directory of a particular repository for the latest revision.  Here’s how we’d more or less want to pull it off with our classes in Ruby:

repo = Repository::RepositoryFactory("svn").open('/some/subversion/repository')
revision = repo.get_latest_revision
# I want all files for the root directory /.
files = revision.all_files('/')

This would provide a collection of File objects representing the files in the latest revision of the repository. If we wanted to download/display that file, we could use the following:

repo = Repository::RepositoryFactory("svn").open('/some/subversion/repository')
revision = repo.get_latest_revision
# Say I wanted the file Test.java from the root directory...
wanted_file = revision.all_files('/')["Test.java"]
file_output = repo.download(wanted_file)
#...insert code here to send file_output to browser

As it stands, that’s more or less how we’re designing the Repository classes. Big thanks to the Basie team for their suggestions on the design!

Anyhow, I’ll try to keep you all posted on our progress for implementing the Repositories.

Written by m_conley

May 25th, 2009 at 12:47 am