Re: SVG Book (was: SVG IG -- a few ideas)

Jon,

Thanks for the background on tagging.

Do you see tagging/branching as really useful for either of these
projects though?

For the book there is only ever going to be one version of it (the
trunk), as far as I can see.  We will just keep refining it until it's
ready to publish.  At that point we may want to branch/tag so that we
'freeze' the published version and then keep working on the trunk (for
a Second Edition, or whatever).

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.

So something like:

.../svn/trunk/Torture1/index.html
.../svn/trunk/Torture1/test-a.svg
.../svn/trunk/Torture1/test-b.svg
.../svn/trunk/Torture1/style.css
...
.../svn/trunk/Torture2/index.html
...
etc

Remember that, like the Acid tests, each Torture test will test a
large variety of corner-cases, basic functionality, etc all in one big
test.

Someone please tell me I'm wrong though :)

Jeff

On Mon, Oct 12, 2009 at 11:43 AM, Jon A. Cruz <jon@joncruz.org> wrote:
>
> On Oct 12, 2009, at 9:05 AM, Jeff Schiller wrote:
>
> Actually I don't really have a problem with tagging in svn, it's just
> a (lightweight) copy but the effect is the same in my experience.
> Maybe you could shed some light on the problems with the tagging
> approach in subversion as I'm sure you have more experience.
>
>
> Yes. Early on the subversion developers declared that tagging was the wrong
> thing to do, and that nobody using a version control system (vcs) should use
> it. I think branching perhaps was considered the same. Anyway, once things
> started hitting public testing there was enough hue and cry about it that
> the developers relented and hacked in tags as just branches.
> The main problem with svn tagging is that they aren't really tags, searching
> for tagged things is hugely expensive, and any substantive project will have
> its tags become unusable. This bit us with Inkscape big-time. When tagging
> is working, it is very useful and gives GUI tools something to track
> merging, etc. with:
> http://www.twobarleycorns.net/tkcvs/screen-branch.html
>
>
> I'm also not sure about support for GUIs for any of these as I'm a
> command-line user.  I'm familiar with TortoiseSVN and that's about it.
>
> I usually used TortoiseCVS and TkCVS in concert when on windows. The *SVN
> versions are comparable.
> Bzr also has better work and such on their GUIs. One big problem I've seen
> with git is that since it was created for an entirely different use case
> (managing emailed kernel patches) those designing it and working on it did
> not conceptualize things in the same ways. As far as the others go, on
> Inkscape we've been tracking things for some time and git and bzr are the
> two current contenders for our needs.
>
> Anyway, I think the Torture Tests and the SVG Book are separate
> projects so we don't need to be in the same repository.  I guess you
> were thinking so that people don't have to learn about two tools
> instead of one, right Jon?
>
> There are two main aspects to what I was thinking
> 1) much easier on people to only have to learn one tool, not two.
> 2) end-user oriented tools that work well cross platform will make both
> projects (book and tests) easier.
> For the second point there are many factors, such as the fact that git is
> focused on Linux kernel work makes them not rank cross-platform line-end
> support as important, etc.
> 2b) availability and progress on GUI tools.
>

Received on Monday, 12 October 2009 17:00:54 UTC