Alan Garny wrote:
Andrew Miller wrote:
Alan Garny wrote:
There are viewable web interfaces for git - see the gitweb at e.g.
http://repo.or.cz/w/cellml-draft-
miller.git?a=tree;h=normative;hb=normative
How does it work?
Using Opera, if I click on blob for abstract.xml, I get:
---
This document is an unofficial working draft. The below describes the
intended status of the specification, and not the current status right now.
This document specifies CellML 1.2, an XML-based language for describing and
exchanging mathematical models. This is the normative specification of
CellML. It is intended to provide the minimum amount of information needed
to accurately describe CellML. An alternative version is available which is
annotated with much more explanatory material.
---
While with Firefox, I get told that [the] XML file does not appear to have
any style information associated with it and get show the document tree.
Using Internet Explorer, I get told that the XML file cannot have multiple
DOCTYPE declarations.
My demo setup uses DocBook together with XInclude to assmeble the
document - if we use DocBook as our source format, we will also need to
provide an easier way to view it - this could be as simple as
referencing an XSL as the style information so people's browsers can
view it - but I don't think this will help with the XInclude as I
believe it is not generally supported in browsers (although we could
create a trivial Javascript XInclude processor and include it in the
repository which would allow people to visualise the latest version in
their browsers, with the only requirement being a Firefox / recent IE /
Opera browser with Javascript enabled).
My point is that I would most likely need to learn about git before being
able to use it. I might do that if that's what you guys end up using, but do
you really expect others to do that? Can you really not opt for a 'simpler'
solution?
git, Mercurial, and Bazaar are really the only automated distributed
version control systems that I know of - if we don't use one of those
then we will end up manually co-ordinating everything that git would do.
I think it is better to have an automated system while still being open
to changes suggested by e-mail, rather than to not have an automated
system at all.
Of course, whatever format we use we will also want a rendered version.
In terms of changes, users who don't do enough work on the specification
to justify setting up a git environment can always propose changes to
the mailing list. If they use git, it just makes it easier for us to
share and merge their changes.
Am I to understand that git has become the solution of choice?
No, this is a proof of concept set-up to facilitate discussion of the
options.
I don't know how many major contributors
to specification development we would have who wouldn't want to install
Cygwin anyway - perhaps if there is anyone who this applies to on the
list now is the time to speak up :).
I would certainly be interested to know indeed. I would be happy to
contribute to the specifications, but I am not willing to install Cygwin for
something that I am not going to use on a daily basis.
Again, there must be an easier solution?!
The MingW based system mentioned below might suit your requirements, or
you perhaps you could use git from a Linux virtual machine that you have
already got set up?
There is an MingW / MSYS based git port as well -
http://msysgit.googlecode.com/files/GitMe-0.4.2.exe - I haven't tried it
myself.
We could use Mercurial - the only issue there is that the only free
hosting I could find ( http://www.assembla.com ) looks like it is part
of some company's business model and so I wouldn't want to rely on it
remaining free - we don't really want to require people who want to set
up their own repositories to rely on that.
I would be interested to hear from people interested in contributing to
CellML, and the kind of solution they would like to see implemented.
Right now, I feel like git is not a suitable solution. What about DocBook
and the other solutions that have been suggested so far?
git, Mercurial, and Bazaar solve quite orthogonal problems to DocBook:
1) git and other similar technologies are used to track the
specification - that is, they allow each person working on
specifications to keep track of what they think should be the latest
version of specification, and create changes relative to that, and share
those changes with other people.
2) DocBook and similar technologies are for representing a particular
version of a document in a computer-readable way that can be converted
to various other formats.
We still need to decide on how we represent our specification regardless
of how we track changes made to it (my example git
