> You _can_ have different documents in different branches, but that's not > really how branches were designed to be used, and I think would be a big > confusing.
Indeed. Given their independent release cycles it would be *much* more natural and convenient to host them in two separate repositories as originally suggested by Rich Signell. That opens the door to using tags and releases as an easy way to provide a persistent record of versioned snapshots. Richard Hattersley From: CF-metadata [mailto:[email protected]] On Behalf Of Chris Barker Sent: 22 September 2014 22:58 To: John Graybeal Cc: CF Metadata List; Gregory, Jonathan Subject: Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github On Mon, Sep 22, 2014 at 1:23 PM, John Graybeal <[email protected]> wrote: I think the key question is are they in sync? If the two documents will generally get released together with one version number than it makes sense to keep them in one repo. But if they are versioned independently, then it's a bit hard to manage having them in one repo. The thing that will be hard is using branching in the first place, for example while managing multiple proposed modifications of the convention. (First, everyone who wants to leverage this approach will have to come up to speed on git and branching and all that; then, we'll have to figure out if/how we want to publish different branches to different builds.) As of today, the rate of change is arguably not high enough to demand that complexity. Well, how much you branch is up to how you mange the project, and how complex it is. While the git maxim is to "branch early, branch often" -- you really don't need to branch much at all if the development of the documents at hind really is pretty linear. And gitHub makes it remarkably easy for a new user to clone, make changes, and submit a pull request, without really knowing what the heck git is doing under the hood. Once there, the added difficult of managing two documents is a very small bit, if you have a branch called standard_names_dev, and a branch called convention_dev. where I envision it getting confusing is using multiple additional branches, to manage draft changes. Though I suppose branch name conventions could manage that OK: At the "top": std_names_master convention_master then other branches should be named somethign like: std_names_my_cool_proposal or convention_an_other_proposal Though while the standard name table is closely related to the standards doc -- it's really kind of a separate project --not sure why it needs to be in the same repo. You _can_ have different documents in different branches, but that's not really how branches were designed to be used, and I think would be a big confusing. I am not sure I understand this. Source code was the original target for systems like this, and different source code files (documents) are everywhere managed in different branches of a single repository, according to their change sets. Sure, but in the usual case there is a single "project" that has a version, etc. It is a collection of whole bunch of different files, and some of those may be added and removed in different branches, but usually all of the branches' essentially represent the SAME project in a different state. and you would merge in the ones you want to do a release. That being said, gitHub.io uses a special branch to publish stuff -- so it can work, but frankly, I find that really painful. But not a big deal -- either way would work fine. Though I agree it takes a little more conscious thought, because git commits are not natively oriented around file-by-file tracking, exactly -- a "commit" is the sate of the whole branch (literally, as a hash...), which usually represents the state of the whole project. I agree with all this. If the initial 2.x team is willing to try GitHub issues, I think it would be a good chance to see if it is a good way forward. But I also like trac so would not be upset if the trac (for issues) + Github (for docs) approach was used. If this is an experiment for the CF 2.* project -- then we don't need the standard name table anyway... As another note, is the idea here that the CF 2.0 standards doc would be developed in DocBook XML? That doesn't seem very amenable to community contributions (anyone could contribute ideas, discussion, etc, but actually patching the docs would get tricky.) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
