This documents some of the discussion regarding what source control provider to use for the RDF representations of the CDISC standards. This is related to the discussion about repository design. This does *not* cover the discussion about final hosting provisions - only for the development of the standards.
Please note that there has previously been an evaluation of Source Code Control systems as part of the Development_of_Standard_Scripts_for_Analysis_and_Programming work - the evaluation is covered in WG5_Project_03.
The final decision in this case was that Google Code Satisfied the requirements of that team.
Providers under consideration
Criteria for Selection
These criteria should suit our requirements, there is a good comparison on Comparison of Revision Control Systems(Wikipedia) that we should make extensive use of. Following are some pertinent considerations
- User Administration
- Merge approaches
- Repository Administration
- Revision Control Systems support
- Downloadable code (outside of client software)
|Cost||Free||Free||Free (for up to 5 users)||Free||Free (for open source)|
|Supports Code Archive download||No||Yes||?||Yes (Zip)||Yes (tar.gz)|
|Authentication||Google Account||Windows Live ID||Bitbucket login/Google Auth||GitHub Account||OpenID/Gitorius|
Gitorius has an interesting concept of having projects and repositories. This is similar to the GitHub concept of an Organisation with associated repositories. Briefly in our scheme we'd probably have cdisc2rdf as the project or organisation, with the individual standards (eg sdtm, cdash, adam) as the repositories. The RDF/OWL files would live in the top level of the repository.
Teams allow templating of user access. We could (not suggesting this is a good possibility) have a cdash-team, sdtm-team, adam-team which grant push (write) access. The teams are associated with the repositories. People allowed to commit to different repositories can be added to teams and they automatically get write access to the repositories.
This is a facet whereby submissions to a repository can be reviewed by a peer prior to the changes being merged in. An example of this is the GitHub Pull Request Using Pull Requests - it is a collaborative affair, where as many people as want to can contribute to the code review. You can comment on individual lines of code, or on the pull request/merge request as a whole. The comments are maintained as part of the repository.