Archive for the ‘SVN/Git backend design’ Category
I plan to work on the git backend branch for the month of March (and beyond).
I’ve created a branch of the wiki (https://github.com/munrocape/Markus/wiki/GitBackEnd) in the hopes of having a more concise and detailed set-up guide for future developers as I personally unlinked/mixed up my symbolic links for ruby and it required a fresh virtual box. Oops!
Note: this post will be updated as the design changes. This is just for other developers who wish to work on the git-backend project.
– Adding a group will create a git repo in /repos (will change)
– New repo has permissions RW+ granted to admins/graders.
1. Checkout my git-conversion branch (will change) https://github.com/drunkel/Markus/tree/git-conversion
2. Install and use ruby 1.9.3
3. Ensure that gems: rugged and gitolite are installed.
4. Create a directory in /data/dev/repos called git_auth
5. in irb, do:
6. Start the server normally.
**These instructions may contain errors, this project is just getting started.
There has been a decline in support for Subversion Ruby bindings as of late. This reduced support is slowing the progression of MarkUs to run on the most recent versions of Ruby and Ruby on Rails. To stay up to date, MarkUs is going to need to move away from using Subversion Ruby bindings and move towards an alternative. Thus far, there are 3 proposed solutions to this problem:
The Subversion bindings are needed for MarkUs to interact with the SVN repos that it manages. This solution would replace the SVN bindings with Git bindings while retaining the SVN repos. Git Ruby bindings are widely supported and updated and are said to interact well with Subversion repositories. In order to use Git bindings, libgit2 (link) and the Ruby gem Rugged (link) will need to be installed for MarkUs to make use of Git functions. Libgit2 and Rugged are common programs found in many larger applications (such as GitHub) and thus there is a better chance of long-term support.
With the diminished support of Subversion as a whole, it would be worth considering replacing SVN completely within MarkUs with Git. This would require the replacement of the SVN bindings and the SVN repos with Git bindings and repos. There is a catch with replacing the SVN repos. Git does not use the same style of repo authorization that SVN does, there is nothing to prevent a MarkUs user from accessing another user’s Git repo(s). The solution for this is to install the Git authorization assistant gitolite (link). Gitolite will implement a ssh key pair system for MarkUs user’s to access their repos. MarkUs Admin’s will manage which students have access to which repos and students will manage which key pairs are bound to their account. Gitolite is used in many applications (again GitHub), and could be a good solution to this problem.
Solution 3 is a hybrid solution of solution 1 and 2. For this solution MarkUs would first have the SVN Ruby bindings replaced by Git bindings and maintain its SVN repos (just like solution 1) and would require the same issue working as the first solution. Once the SVN bindings are replaced MarkUs can then add (in addition to SVN repos) Git repositories like solution 2, again with the same process as the second solution. The idea behind this solution is that MarkUs would eventually support both SVN and Git for version control and would allow the MarkUs admins to decide which they would prefer their students to work with. Not all schools teach SVN and not all schools teach Git, this would allow MarkUs a broader reach to assignment markers. Because of the high level of modularity required to support both SVN and Git concurrently, it could be possible for MarkUs to support addition version control systems (such as Mercurial Or CVS) in the future.
These are the solutions that there were brainstormed. If anyone has any solutions, information, direction, ideas, and/or helpful tips as how to proceed, please comment or message the MarkUs-Devs.
(Special thanks to Bill for writing this up!)