Repository organization woes. (Translators, please read this!)

C. Michael Pilato cmpilato at
Tue Aug 9 22:30:54 CDT 2011

I'm stumped.  I'm trying to find some rhyme or reason in the organization of
the svnbook repository, and I simply cannot do it.

We have a trunk in which can be found some shared tools/ and the source code
for N different translations, each of which is tracking a potentially
different version of the book itself, and all but 3 (I think) which are
effectively dead.

   de - Subversion 1.5 (active)
   en - Subversion 1.7 (active)
   es - Subversion 1.0 (dead -- last commit Mar 2007)
   fr - Subversion 1.5 (active)
   it - Subversion 1.2 (dead -- last commit Mar 2008)
   nb - Subversion 1.4 (dead -- last commit Aug 2008)
   ru - Subversion 1.4 (dead -- last commit Mar 2009)
   zh - Subversion 1.6 (dead -- last commit Feb 2011)

I'd like to begin having long-lived branches so that some of the older
versions of the English text can be updated with fixes and remain active.

What can be done?

Since I can't imagine that any translation project would wish to actively
track a moving target (is this true?), I'm considering moving all the
translations into branches based on the version number of the English source
they are "chasing".  The English source would be the only thing in the
trunk.  So, the current directories would be moved like so:

   trunk/src/en  ->  trunk/en/
   trunk/src/de  ->  branches/1.5/de
   trunk/src/es  ->  branches/1.0/es
   trunk/src/fr  ->  branches/1.5/fr
   trunk/src/it  ->  branches/1.2/it
   trunk/src/nb  ->  branches/1.4/nb
   trunk/src/ru  ->  branches/1.4/ru
   trunk/src/zh  ->  branches/1.6/zh
   trunk/src/tools -> trunk/tools (but also copied to each branch)

I would then generalize the nightly build process to allow for these
disparate locations of the sources, as well as to allow multiple builds for
a given translation if various versions of it remain active (which is
probably only going to ever be true for the English version).

Does this make sense?  Are there some other, better suggestions out there?

C. Michael Pilato <cmpilato at> |

More information about the svnbook-dev mailing list