Re: [cellml-discussion] Proof of concept: using git for specification development
How to for Windows users: git and docbook. There are other ways of doing this, but the following worked. Overview: A)Initial setup A1) Install Msys/Git A2) Git checkout of CellML spec docbook source A3) Installation of xsltproc A4) Installation of docbook-xsl B)Routine operations Details: A) Initial setup: A1) MSys and Git: A1.1) Note: the installer does not seem to work from behind a firewall if the firewall blocks direct outward connections. A1.2) Note: in the next step, you can choose the install target directory. I'll assume the default was used "C:\msysgit" and refer to it later. A1.3) Download and run http://msysgit.googlecode.com/files/GitMe-0.4.2.exe A2) Checkout: A2.1) Run msys (see step B1) A2.2) Execute the git commands as per Andrew's e-mail, repeated here: git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version cd andrews-spec-version git checkout -b normative remotes/origin/normative A3) xsltproc: A3.1) Follow the instructions at http://www.sagehill.net/docbookxsl/InstallingAProcessor.html#InstallXsltproc , just the short section under "Installing xsltproc on Windows" A4) docbook-xsl A4.1) Note: The path in the next step assumes the default was chosen for step A1.2, so adjust this as necessary. A4.2) Make the following subdirectories under the Msys/share directory for the xsl files: C:\msysgit\share\xml\docbook\stylesheet\nwalsh A4.3) Download latest version (currently docbook-xsl-1.73.2.zip) from http://sourceforge.net/projects/docbook/ A4.4) Unzip the contents into the directory referred to in A4.2 B) Routine use B1) Run "msys.bat" (it is located in the directory chosen in step A1 above. It opens a terminal window, and one can operate the command line tools in a similar fashion to a Linux/Unix like OS. B2) cd to "andrews-spec-version" B3) Get the latest updates if you want: "git pull" (Note: I'm still new to git, so there may be variations here.) B4) Run "./genspec.sh" B5) This should have generated "toplevel.xhtml" B6) Browse the generated spec: "explorer toplevel.xhtml" (Note that somehow Firefox will launch here if it is your default browser J) This should allow you to at least keep up with any changes in the original repository. Regards, Randall > -Original Message- > From: [EMAIL PROTECTED] [mailto:cellml-discussion- > [EMAIL PROTECTED] On Behalf Of Andrew Miller > Sent: Monday, 12 November 2007 10:22 a.m. > > 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. > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Hi all Some time has passed since the last discussions on this thread, and the preceding thread "Representing the next version of the CellML Specification". To summarise: Various possible technologies for managing the specification development were discussed, please see the relevant postings for details. Following the first discussion, a prototype of the apparently most suitable combination has been set up by Andrew Miller as follows: 1) Git is being used for distributed version control. 2) Docbook is being used for the document format. The e-mails on these threads raised various pros and cons of each of this configuration. To address the cons of the above setup, the following policy will be adopted: Not all participants in the specification process will be expected to directly use these tools. Members of the Auckland CellML team will to act as "proxy" editors for those who opt not to use the above tools directly. At the Auckland CellML meeting of 14 November, it was suggested that we round up this discussion within the next week. We are of the view that the above system will work out best, when all things are taken into consideration. So, the next step is to try and use the above system and policy, and raise any major concerns by 21 November by mailing this list on this thread. Our goal will be to work-around any issues if possible. If not, we will reassess, and potentially restart the prototyping stage. Regards, Randall Britten ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
> -Original Message- > From: [EMAIL PROTECTED] [mailto:cellml-discussion- > [EMAIL PROTECTED] On Behalf Of Randall Britten > Sent: 12 November 2007 00:16 > To: 'CellML Discussion List' > Subject: Re: [cellml-discussion] Proof of concept: using git for > specification development > > Hi all > > Can I suggest that we will cater for anyone wanting to contribute to the > spec, but who does not want the hassle of setting up and learning to use > git > by finding a solution that will allow them to use something simpler. > > One idea is that someone else who already has git setup could "proxy" > for > them. They could just e-mail their amendments to their proxy, and their > proxy would submit those to a separate git, or to a branch. > > In all likelihood we will soon find a user-friendly tool (e.g. some web > interface or small app) that will allow anyone to easily use git > directly > (e.g. something similar to TortoiseSVN for Windows). I think that would be essential. I have no doubt that you (Auckland, that is) know what is best for the CellML community, but I want to think that to keep/get the community involved, we have to provide a 'simple' solution (that hides all the 'complexity' of whatever solution you guys deem essential to have). Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Hi all Can I suggest that we will cater for anyone wanting to contribute to the spec, but who does not want the hassle of setting up and learning to use git by finding a solution that will allow them to use something simpler. One idea is that someone else who already has git setup could "proxy" for them. They could just e-mail their amendments to their proxy, and their proxy would submit those to a separate git, or to a branch. In all likelihood we will soon find a user-friendly tool (e.g. some web interface or small app) that will allow anyone to easily use git directly (e.g. something similar to TortoiseSVN for Windows). Regards, Randall ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Bob Gustafson wrote: > On Mon, 2007-11-12 at 10:21 +1300, Andrew Miller wrote: > snip > > >> 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. >> >> Best regards, >> Andrew >> > > I clicked on http://www.assembla.com/ and searched for Mercurial. No > hits! > See http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting - I think that part of the Assembla free offering includes Mercurial hosting. > > > As I understand the way that git/Mercurial would be used - whoever is > the corralmeister needs access to author's server(s) which store > external versions of the cellml specs/software/... As these various > external versions are vetted in some way, they need to be accessed and > merged to form the latest community version. > Although this 'vetting' process is really community discussion, and will take a long time for consensus to be reached. In the mean time many users are likely to also want to pull in other author's work so they can create improved versions of it (or just to view it to help them form an opinion, see how it interacts with other proposed changes, etc...). > Since this access and merge is asynchronous to the activities of > individual authors, a public IP address for these external servers would > be helpful. > > Perhaps a full blown hosting service is not necessary for this? > Hosting of repositories can be set up in a matter of minutes with many of the free hosting services - this is often easier than going through IT processes to get something made public any other way. However, authors who have the ability to easily make their repository public some other way would of course not need to worry about this. > Also, these days, 'free' implies some sort of advertising views. > I believe that http://repo.or.cz/ is made available for Open Source git hosting by one of the authors of git, and it doesn't seem to contain advertising - it is more an effort to promote git / provide a service to the open source community. Assembla is a commercial outfit, but they also don't seem to put up third party advertisements - rather, their business model seems to involve selling consulting and using the community of developers using their hosting to build their profile. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
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 o
Re: [cellml-discussion] Proof of concept: using git for specification development
On Mon, 2007-11-12 at 10:21 +1300, Andrew Miller wrote: snip > 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. > > Best regards, > Andrew I clicked on http://www.assembla.com/ and searched for Mercurial. No hits! As I understand the way that git/Mercurial would be used - whoever is the corralmeister needs access to author's server(s) which store external versions of the cellml specs/software/... As these various external versions are vetted in some way, they need to be accessed and merged to form the latest community version. Since this access and merge is asynchronous to the activities of individual authors, a public IP address for these external servers would be helpful. Perhaps a full blown hosting service is not necessary for this? Also, these days, 'free' implies some sort of advertising views. Bob G ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Andrew Miller wrote: > Alan Garny wrote: > >> git is also a distributed version control system - the two tools have > a > >> fairly similar conceptual model in terms of how they work, with a lot > of > >> flow of ideas between the too tools. I have found git slightly faster > >> and a bit more extensible (and with a larger set of commands out-of- > the > >> box), although one downside is that git front-ends are largely > written > >> in shell-script, which means you Cygwin to use it on Windows. > >> > > That's a big downside in my opinion. We cannot seriously expect some > Windows > > users interested in CellML to install Cygwin only to be able to change > the > > specifications. > > > > Is there really no 'simple' web interface that could be used and that > is > > still 'acceptable'? If you want to get the community involved, you > want > > something as 'simple' as plug-n-play, not something that involves > tweaking > > things around. > > > 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 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? > 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? > 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?! > 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? Something that should be kept in mind: to go for a solution that suits the CellML team is one thing, but to have a solution that suits the community is probably even more important (that is if you want the community to be involved!). Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Alan Garny wrote: >> git is also a distributed version control system - the two tools have a >> fairly similar conceptual model in terms of how they work, with a lot of >> flow of ideas between the too tools. I have found git slightly faster >> and a bit more extensible (and with a larger set of commands out-of-the >> box), although one downside is that git front-ends are largely written >> in shell-script, which means you Cygwin to use it on Windows. >> > > That's a big downside in my opinion. We cannot seriously expect some Windows > users interested in CellML to install Cygwin only to be able to change the > specifications. > > Is there really no 'simple' web interface that could be used and that is > still 'acceptable'? If you want to get the community involved, you want > something as 'simple' as plug-n-play, not something that involves tweaking > things around. > 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 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. 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 :). 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. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
> git is also a distributed version control system - the two tools have a > fairly similar conceptual model in terms of how they work, with a lot of > flow of ideas between the too tools. I have found git slightly faster > and a bit more extensible (and with a larger set of commands out-of-the > box), although one downside is that git front-ends are largely written > in shell-script, which means you Cygwin to use it on Windows. That's a big downside in my opinion. We cannot seriously expect some Windows users interested in CellML to install Cygwin only to be able to change the specifications. Is there really no 'simple' web interface that could be used and that is still 'acceptable'? If you want to get the community involved, you want something as 'simple' as plug-n-play, not something that involves tweaking things around. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Sounds pretty good. Bob G On Sun, 2007-11-11 at 15:16 +1300, Andrew Miller wrote: > Bob Gustafson wrote: > > Besides git, there is Subversion and a new distributed SCM: Mercurial > > > > http://www.selenic.com/mercurial/wiki/ > > > > Being distributed, it may have advantages for cellml, considering the > > worldwide spread of cellml participants. > > git is also a distributed version control system - the two tools have a > fairly similar conceptual model in terms of how they work, with a lot of > flow of ideas between the too tools. I have found git slightly faster > and a bit more extensible (and with a larger set of commands out-of-the > box), although one downside is that git front-ends are largely written > in shell-script, which means you Cygwin to use it on Windows. > > There are tools such as tailor which can probably perform two-way merges > between the two systems (I haven't tried). > > As a centralised system, Subversion is probably not very usable for > specification development, because it means you have a single, > centralised version of the specification (although you could create > branches, but it still requires permissions be granted to people just to > create branches), while git / Mercurial / Bazaar can do that sort of > thing out of the box. > > It is not really the physical location which gives distributed version > control systems the big win, but rather, the fact that creating an > official specification requires that numerous proposed changes, > sometimes mutually exclusive, from people who may not know each other, > be written up and maintained, and as consensus begins to be reached, get > merged together to form a final, official specification. There have been > lots of ideas proposed, but because we don't yet really have good > processes for going from proposals to the concrete text of the > specification, nothing has really come out of these proposals yet. > > If we choose to use a distributed VCS system like git for this, I can > create my personal specification repository, and others can create their > repositories too (perhaps derived from my version for example), make > some changes, and then announce them on the mailing list. At this point, > if the consensus seems to be that these changes should be in the > specification, I could pull them into my repository. Eventually, when > there don't seem to be any more changes being discussed, someone who has > been curating changes accepted by consensus in their repository can > propose that this curated version becomes the official version, and if > the community agrees, we will have a specification, complete with the > merged revision histories from everyone who worked on it. > > Best regards, > Andrew > > > > > Bob G > > > > On Thu, 2007-11-08 at 13:44 +1300, Andrew Miller wrote: > >> Hi all, > >> > >> As a proof of concept, I have set up an unofficial CellML specification > >> git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is > >> intended to show the concept of using a distributed revision control > >> tool to work on specification development, and not to suggest that this > >> is necessarily the type of technology which will be used for the actual > >> specification development. > >> > >> I have used DocBook as the source format in this repository based on the > >> preliminary consensus on the CellML discussion mailing list - again, > >> this is not intended to suggest that DocBook will be the final format > >> used for specification development, but to show the concept, as one > >> format or another needs to be chosen even at he proof-of-concept stage. > >> > >> git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version > >> cd andrews-spec-version > >> git checkout -b normative remotes/origin/normative > >> > >> You now have a local repository of my unofficial draft version of the > >> specification. You can make and commit your own changes locally, and > >> potentially push them to your own publicly visible repository (which > >> would allow me, or someone else to pull the changes into my version). > >> This makes it easy for everyone to keep their own draft versions, and > >> merge in changes that they agree with from others. We could eventually > >> set up an official git where changes which become widely accepted are > >> pushed, and to provide a starting point for people wanting to propose > >> additional changes. > >> > >> BTW on my system, I can generate the HTML output using: > >>xsltproc --xinclude --param section.autolabel 1 > >> /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml > >> >toplevel.xhtml > >> > >> The exact command you should use will depend on where things are > >> installed on your system. > >> > >> Best regards, > >> Andrew > >> > >> ___ > >> cellml-discussion mailing list > >> cellml-discussion@cellml.org > >> http://www.cellml.org/mailman/listinfo/cellml-d
Re: [cellml-discussion] Proof of concept: using git for specification development
Bob Gustafson wrote: > Besides git, there is Subversion and a new distributed SCM: Mercurial > > http://www.selenic.com/mercurial/wiki/ > > Being distributed, it may have advantages for cellml, considering the > worldwide spread of cellml participants. git is also a distributed version control system - the two tools have a fairly similar conceptual model in terms of how they work, with a lot of flow of ideas between the too tools. I have found git slightly faster and a bit more extensible (and with a larger set of commands out-of-the box), although one downside is that git front-ends are largely written in shell-script, which means you Cygwin to use it on Windows. There are tools such as tailor which can probably perform two-way merges between the two systems (I haven't tried). As a centralised system, Subversion is probably not very usable for specification development, because it means you have a single, centralised version of the specification (although you could create branches, but it still requires permissions be granted to people just to create branches), while git / Mercurial / Bazaar can do that sort of thing out of the box. It is not really the physical location which gives distributed version control systems the big win, but rather, the fact that creating an official specification requires that numerous proposed changes, sometimes mutually exclusive, from people who may not know each other, be written up and maintained, and as consensus begins to be reached, get merged together to form a final, official specification. There have been lots of ideas proposed, but because we don't yet really have good processes for going from proposals to the concrete text of the specification, nothing has really come out of these proposals yet. If we choose to use a distributed VCS system like git for this, I can create my personal specification repository, and others can create their repositories too (perhaps derived from my version for example), make some changes, and then announce them on the mailing list. At this point, if the consensus seems to be that these changes should be in the specification, I could pull them into my repository. Eventually, when there don't seem to be any more changes being discussed, someone who has been curating changes accepted by consensus in their repository can propose that this curated version becomes the official version, and if the community agrees, we will have a specification, complete with the merged revision histories from everyone who worked on it. Best regards, Andrew > > Bob G > > On Thu, 2007-11-08 at 13:44 +1300, Andrew Miller wrote: >> Hi all, >> >> As a proof of concept, I have set up an unofficial CellML specification >> git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is >> intended to show the concept of using a distributed revision control >> tool to work on specification development, and not to suggest that this >> is necessarily the type of technology which will be used for the actual >> specification development. >> >> I have used DocBook as the source format in this repository based on the >> preliminary consensus on the CellML discussion mailing list - again, >> this is not intended to suggest that DocBook will be the final format >> used for specification development, but to show the concept, as one >> format or another needs to be chosen even at he proof-of-concept stage. >> >> git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version >> cd andrews-spec-version >> git checkout -b normative remotes/origin/normative >> >> You now have a local repository of my unofficial draft version of the >> specification. You can make and commit your own changes locally, and >> potentially push them to your own publicly visible repository (which >> would allow me, or someone else to pull the changes into my version). >> This makes it easy for everyone to keep their own draft versions, and >> merge in changes that they agree with from others. We could eventually >> set up an official git where changes which become widely accepted are >> pushed, and to provide a starting point for people wanting to propose >> additional changes. >> >> BTW on my system, I can generate the HTML output using: >>xsltproc --xinclude --param section.autolabel 1 >> /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml >> >toplevel.xhtml >> >> The exact command you should use will depend on where things are >> installed on your system. >> >> Best regards, >> Andrew >> >> ___ >> cellml-discussion mailing list >> cellml-discussion@cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
Besides git, there is Subversion and a new distributed SCM: Mercurial http://www.selenic.com/mercurial/wiki/ Being distributed, it may have advantages for cellml, considering the worldwide spread of cellml participants. Bob G On Thu, 2007-11-08 at 13:44 +1300, Andrew Miller wrote: > Hi all, > > As a proof of concept, I have set up an unofficial CellML specification > git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is > intended to show the concept of using a distributed revision control > tool to work on specification development, and not to suggest that this > is necessarily the type of technology which will be used for the actual > specification development. > > I have used DocBook as the source format in this repository based on the > preliminary consensus on the CellML discussion mailing list - again, > this is not intended to suggest that DocBook will be the final format > used for specification development, but to show the concept, as one > format or another needs to be chosen even at he proof-of-concept stage. > > git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version > cd andrews-spec-version > git checkout -b normative remotes/origin/normative > > You now have a local repository of my unofficial draft version of the > specification. You can make and commit your own changes locally, and > potentially push them to your own publicly visible repository (which > would allow me, or someone else to pull the changes into my version). > This makes it easy for everyone to keep their own draft versions, and > merge in changes that they agree with from others. We could eventually > set up an official git where changes which become widely accepted are > pushed, and to provide a starting point for people wanting to propose > additional changes. > > BTW on my system, I can generate the HTML output using: >xsltproc --xinclude --param section.autolabel 1 > /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml > >toplevel.xhtml > > The exact command you should use will depend on where things are > installed on your system. > > Best regards, > Andrew > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proof of concept: using git for specification development
> As a proof of concept, I have set up an unofficial CellML specification > git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is > intended to show the concept of using a distributed revision control > tool to work on specification development, and not to suggest that this > is necessarily the type of technology which will be used for the actual > specification development. > > I have used DocBook as the source format in this repository based on the > preliminary consensus on the CellML discussion mailing list - again, > this is not intended to suggest that DocBook will be the final format > used for specification development, but to show the concept, as one > format or another needs to be chosen even at he proof-of-concept stage. > > git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version > cd andrews-spec-version > git checkout -b normative remotes/origin/normative > > You now have a local repository of my unofficial draft version of the > specification. You can make and commit your own changes locally, and > potentially push them to your own publicly visible repository (which > would allow me, or someone else to pull the changes into my version). > This makes it easy for everyone to keep their own draft versions, and > merge in changes that they agree with from others. We could eventually > set up an official git where changes which become widely accepted are > pushed, and to provide a starting point for people wanting to propose > additional changes. > > BTW on my system, I can generate the HTML output using: >xsltproc --xinclude --param section.autolabel 1 > /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml > >toplevel.xhtml > > The exact command you should use will depend on where things are > installed on your system. Though I do have a Linux virtual machine, my main working environment is Windows. So, how do I go about using git? My point is that if you want to involve the community (which I understand you do), then you have to provide a solution that not only suits your needs, but all those of the community. In other words: opt for a solution that is as easy as possible to use and this from any platform. It seems to me that, until now, we have only given a list of possible solutions (together with their pros and cons) and that's fine, but what do we exactly want from that solution? Personally, I would favour a solution that: - is web-based (so anyone can have access to it from anywhere), - could be used by non-computer specialists (indeed, let's not forget that someone interested in CellML doesn't necessarily mean someone who is capable to understand or willing to learn some, if not all, of the technologies that have been discussed so far), - provides a useful history of changes (i.e. the diff feature discussed before), - uses an XML-based internal format (I believe this would be useful if we think long-term strategy, which we obviously should!), but that certainly doesn't mean that we should have to manipulate that format directly (see my 2nd point above), - can convert the internal format to a nicely formatted PDF file (and maybe other formats?). Just a few thoughts... PS: "you" is used to mean "the Auckland CellML team". PPS: http://www.cellml.org/ seems to be 'dead', even though I can tracert/ping it... ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] Proof of concept: using git for specification development
Hi all, As a proof of concept, I have set up an unofficial CellML specification git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is intended to show the concept of using a distributed revision control tool to work on specification development, and not to suggest that this is necessarily the type of technology which will be used for the actual specification development. I have used DocBook as the source format in this repository based on the preliminary consensus on the CellML discussion mailing list - again, this is not intended to suggest that DocBook will be the final format used for specification development, but to show the concept, as one format or another needs to be chosen even at he proof-of-concept stage. git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version cd andrews-spec-version git checkout -b normative remotes/origin/normative You now have a local repository of my unofficial draft version of the specification. You can make and commit your own changes locally, and potentially push them to your own publicly visible repository (which would allow me, or someone else to pull the changes into my version). This makes it easy for everyone to keep their own draft versions, and merge in changes that they agree with from others. We could eventually set up an official git where changes which become widely accepted are pushed, and to provide a starting point for people wanting to propose additional changes. BTW on my system, I can generate the HTML output using: xsltproc --xinclude --param section.autolabel 1 /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml >toplevel.xhtml The exact command you should use will depend on where things are installed on your system. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
