I used this last year, they gave me an org and private repos for the student projects without any fuzz, it was really cool to teach a course with that and we open sourced the projects afterwards (it's in spanish, though) : https://github.com/progra4
I'll definitely use it again, the students learned a lot about project management and distributed version control systems, which is something that isn't being taught as it should, at least not where I went to college.
Sounds great! Assembla used to do this, but this seems a great way to learn Git. Students need to learn to understand SVN, some just don't get it. Git is a step on top of that, but very important to learn.
Some colleges do teach project management by just doing it: I spent a quarter of my 4 years doing full-time projects.
I would love to hear that there are CS/EE programs using version control to catch cheating. It seems to me that if you forced students to "show their work" by having them commit to their project repo in small increments, it would obviate (some of) the hoops some depts seem to go through to prevent cheating.
At my school, we were given programming problems a week in advance, told to solve them and memorize the solutions, and then had to show up at a computer lab for an "exam" where we basically typed the programs in and made sure they compiled, etc. I believe this process was put in place after rampant cheating was happening in more traditional "turn in your source code" types of projects. However, this was a pretty horrid experience, and for some students who treated them like regular exams (ie didn't actually memorize working solutions beforehand) these exams were crushing to their grades.
I can imagine some sort of automated checker for this, examining repos for unusual activity (one giant commit right at due date) after a project was submitted. Of course, I've also heard that in some academic CS depts, any version control at all is a huge deal (we were taught how to use the integrated CVS tools in Eclipse in one afternoon by some TAs, and that was the extent of my exposure to vc in the classroom, and this was in 2006-7), so maybe I'm dreaming too much.
I tried to use this approach last semester in a course I taught and found out that it isn't easy to get used to an SCM the first time, so regular and good students end up doing huge and late commits, moreover, one of the worse performing students learnt -ironically- to alter the git log to seem more diligent than he actually was (lots of commits and files changed), and with stuff like git rebase, a more clever cheater could never actually get caught. So an approach strongly reliant on the SCM kinda weakens in practice(though, as you point out, it could be used as a _secondary indicator_ or guarantee of work). And in theory, as other commenters say, taken to extremes, one ends up evaluating secondary things and overseeing essential things like the ability to rationally defend the code and explain one's approach.
Nevertheless, it is feasible to set up stuff like post-commit hooks (I actually used 'em to monitor the turn ins to an exam) to maybe submit the code to an automated plagiarism detector like [moss](http://theory.stanford.edu/~aiken/moss/), that would be cool, maybe I'll try that out next semester.
Yeah, there are definitely a lot of things I didn't think of which would make this somewhat ineffective.
> one ends up evaluating secondary things and overseeing essential things like the ability to rationally defend the code and explain one's approach.
This seems to describe exactly the problem with the exams I had, which tested more the ability to memorize a solution and regurgitate it in a test setting. This is of course anecdotal, but I've heard of similar exams in other schools. So I think there's a lot of room for improvement there.
"I would love to hear that there are CS/EE programs using version control to catch cheating. It seems to me that if you forced students to "show their work" by having them commit to their project repo in small increments, it would obviate (some of) the hoops some depts seem to go through to prevent cheating."
I know several professors that attempt this. The work-around is pretty trivial though: just cheat as usual, then claim you forgot to commit until you were already done. The best the professor can really do in those cases is dock the kids a letter-grade or so (oh noes, a B!), since forgetting to commit is at least somewhat plausible for students unused to version control, and certainly isn't strong evidence of cheating.
Of course the really bad cheaters are still caught, but through the tried and true method of comparing code and looking for students that don't understand their own code.
That requires professors to be much "tougher" than they often like to be. Completely failing an assignment for reasons not actually relating to the content of the assignment is pretty unpopular here, among everybody.
It's also not impossible to fake a revision history (in fact, it's pretty damned easy), so if you start flat out failing kids only the honest students will get "caught".
> That requires professors to be much "tougher" than they often like to be.
If a prof/TA can't be bothered to police their students then they forfeit any right to complain about cheating.
If students can't follow directions (give grace on the first offence, maybe) then letting them slide does a disservice to their future.
As for cheaters: I don't mind whether or not really determined cheaters can sneak through. They are only cheating themselves in the long run. A system that only catches the 'honest' kids is still a good system because only the 'honest' students will generally make any attempt to mend their ways.
profs/TAs certainly can catch cheaters though, and they're pretty good at it without resorting to extreme measures.
Instantly failing anybody who isn't comfortable with version control is the type of scorched earth tactic that you'd expect the TSA to dream up if they were in charge of catching cheaters.
I am not advocating any sort of Zero Tolerance policy (e.g. "instantly failing") for this. In fact, I think ZT is insane in most if not all cases.
For the purposes of this discussion (which was about having students use version control for assignments) using version control is as central to the requirements as implementing the algorithm and using the assigned language and failure to follow instructions can, at the instructor's discretion, result in grading penalties. As a bonus, this adds another hurdle for cheaters to clear and provides another opportunity for profs/TAs to notice anything suspicious.
> That requires professors to be much "tougher" than they often like to be.
In my case, students were being failed (actually, given 0 credit) because the solutions to the exams wouldn't compile. That's pretty tough, I think. Especially for CS 101.
Eh, in CS 101 getting you program to compile is basically the entirety of the assignment. I think it's pretty unrealistic to expect TAs to spend time figuring out why you couldn't even get your program to build, let alone work.
If you are worried about overloading them with technical info, I find it really easy to introduce people to version control with a "Contributing to a Book" metaphor. Where you have multiple authors and editors all working on a book at the same time, and it's important to know who changed what, and when.
Then, have them start using Git/SVN/Whatever to control any papers, notes, or assignments. I've taught multiple non-developer types how to use version control using this method.
That'd be my gut reaction too, but that might just be because we understand the importance of it. Attrition rates are really high in intro CS classes. When loops still seem like a difficult concept, is version control just one more thing too much? On the other hand, if you spend time before starting programming just learning version control with plain English text, are you encouraging students to drop because they're not getting to program like they expected? And when most projects are 10 to 15 lines long and done alone, is there an effective way to still show how version control is superior to the undo button?
A related but somewhat off-topic question: when do you start using version control on brand-new projects? I find myself hg initing and making my first commit once I've written something significant -- say around 150-200 lines of code.
They've been doing this less formally for a while. Last semester I sent them an email and within a day or so had a free private repository for a school project. It's both a great service and a smart financial move; the type of person who is likely to request a free student repository is extremely likely to do paid business with them in the future (i.e. after graduation).
I didn't realize that they have a student plan and I have applied with hope of getting this free micro plan.
In the past about 2 months, I have started using GIT and its simply brilliant for all types of version control whether development with other programmers or development on my own.
I just sent something to them regarding this as a student. I planned on using github this semester but I'm worried about having my code copied. I'm assuming they provide private repos for students? I'm not sure how successful I'd be getting professors to use github if they already have their own process. But I'd like my code in source control even if I end up submitting the final product some other way.
I'll definitely use it again, the students learned a lot about project management and distributed version control systems, which is something that isn't being taught as it should, at least not where I went to college.