- From: Jon A. Cruz <jon@joncruz.org>
- Date: Mon, 12 Oct 2009 20:39:30 -0700
- To: SVG IG List <public-svg-ig@w3.org>
- Cc: Jeff Schiller <codedread@gmail.com>, "G. Wade Johnson" <gwadej@anomaly.org>, Helder Magalhães <helder.magalhaes@gmail.com>, "David P. Dailey" <david.dailey@sru.edu>, Doug Schepers <schepers@w3.org>
On Oct 12, 2009, at 10:00 AM, Jeff Schiller wrote: > Jon, > > Thanks for the background on tagging. > > Do you see tagging/branching as really useful for either of these > projects though? Tagging is the number one thing I can think of. The second edition of a book, for example, should be distinct from the first. And if errata need to be generated, having a tagged base to know of is good. Release branching is also a factor. One could even view a first publication of a book as going onto a branch. Then errata for that first edition could be tweaks to that branch, optionally merged in to the second edition being developed on the trunk. If something no longer applies, then one doesn't need to "merge" that one, etc. > For the torture tests, my intention is to have several folders (one > for each test) and to basically have one version of each of these > tests (i.e. the trunk again). Thus, we just continue to work on the > test (and the sub-tests) until things are finalized and publish Test 1 > to the web-at-large. There is no 'versions' of the tests, just the > absolute latest official version. If someone finds a bug, we will > update that sub-test and re-publish the latest. I don't ever see a > need to branch the torture tests. For the tests, I can imagine it could be useful to have some subsets/ modules etc. that are split up. So it could be possible that a better way to organize is with a few projects each with their own trunk. What comes to mind is SVG Tiny, SVG Full, etc. For an initial set of tests we may not need that, but for later ones we could. However... the main benefit can come from branches for development tweaking. As each person/group/company/whatever works on refining a test or sets of tests, they can be checking into a branch as they go along. This allows for better collaboration, and avoids the problem of someone "breaking" the trunk. This also allows for easier experimentation and a "safer" way for newer contributors to get involved with less risk. A DCVS such as git or bzr can really help in such cases.
Received on Tuesday, 13 October 2009 03:40:05 UTC