Translation citizenship -- tree reorg needed?

C. Michael Pilato cmpilato at red-bean.com
Fri Jan 30 13:28:13 CST 2009


Ever since the first time the English book team needed to create a tag, I've
felt icky about our tree structure.  Today, we have:

   trunk/
      src/
         en/
         de/
         ...
         tools/
      www/
   tags/
   branches/

This is fine, but to the casual browser might lead folks to assume that all
the translations are working on the same version as the current English
text.  That's just flatly untrue.  And when we tag the trunk, we have to
give it a name like 'en-1.1-final' to imply that, even though all the other
translations are in there, too, this tag ain't about them.  That's weird.
I'd like to remedy this somehow, but I'm not sure how to best do so.

We could do something like this:

   www/
   src/
      en/
         trunk/
         tags/
         branches/
      de/
         trunk/
         tags/
         branches/
      ...

But where do we then put the currently-shared tools/ directory?  (Simple
fix: stop sharing it.)

We could instead take a version-specific approach:

   trunk/
      src/
         1.0/
            en/
            de/
            ...
            tools/
         1.1/
            ...
      www/

But this would almost imply that we are continuing to maintain old doc
versions, which we don't.  (It's almost like taking the trunk and the
branches concepts and combining them into a single tree that's essentially a
collection of branches.)  And anyway, I'm not sure it helps the non-English
translations maintain a real identity.

Part of the problem is that I don't understand how the translation teams
prefer to work.  Is it easier to track the English trunk HEAD forever, or is
it easier to work off a tag of an English version?

What can this project due to encourage success in the translations?  What
directory structure -- or what other feasible change -- makes the best sense?

-- 
C. Michael Pilato <cmpilato at red-bean.com> | http://cmpilato.blogspot.com/




More information about the svnbook-dev mailing list