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

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.