19. Make repository resource a hash

[Note, a separate "Make repository more machine readable" proposal
has been merged into this one.]

Proposal:

Currently we have a simple URL for the repository contained in the
resources/repository key.  It would be good if more information could be
specified in order to allowed automated tools to do manipulations on the
repository rather than the shipped distribution

I suggest that we (optionally?) allow a hash of data to be stored in
repository:

* A distinct URL for the web front end to the repsotitory and the
  repository itself

* The repository format (cvs, svn, darcs, git, etc)

* The repository type (free form string, but I'm thinking "sourceforce"
  "github" etc, that would allow automated tools that know how to use
  repositories that function like those webhosts to do the right thing

For example:

  resources:
     repository:
        web: http://github.com/2shortplanks/test-time-hires
        url: git://github.com/2shortplanks/test-time-hires.git
        format: git
        type: github

Comments:

* Should format be constrained? (Dagolden)

* What would format actually mean? (AdamKennedy)

* "format" would indicate which version control system to disambiguate http
  urls.  E.g. an http URL could be a subversion repo or a git repo (which
  doesn't require a ".git" suffix).  (Dagolden)

* Is it possible that a distribution has multiple repositories? Note that
  www.ohloh.net allows multiple "enlistments" per project. (SlavenRezic)

* A proviso for branch-names and purposes ( or just names ) might also wish
  to be considered, (kentnl) ie:

    repository:
      - format: git
        url: http://git.example.com/some-repo.git
        browser: http://gitweb.example.com/?p=some-repo.git
        purpose: releases
        branch: releases
      - format: git
        url: http://git.example.com/some-repo.git
        browser: http://gitweb.example.com/?p=some-repo.git
        purpose: "patches to"
        branch: master

* The repository is meant to be a permanent resources and could be listed
  for years, branches are by definition ephemeral and will go away,
  recommend against the branches --Adam K

* After thinking about this for a while I wonder if we should keep the use
  of repostiory as it is now and add a second key called "version-control"
  that has the broken down info.  This would make our META.yml more
  verbose, but would mean that it was backwards compatible with clients
  that only know how to read plain strings in repository

Reply via email to