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 >> [email protected] >> http://www.cellml.org/mailman/listinfo/cellml-discussion > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
