CM policy for for svnbook 1.5 translations

C. Michael Pilato cmpilato at red-bean.com
Wed Sep 17 19:34:19 CDT 2008


Johans Marvin Taboada Villca wrote:
> The inability to create branches and tags for translations (it would
> have been unnatural to create translation branches and tags inside
> main trunk) has lead some translation teams to get distanced more and
> more from trunk (I know we can use revision numbers, but is clumsy).
> How have the other translation teams worked in this respect?

I don't understand this bit.  Where did this "inability to create branches
and tags for translations" come from?  We don't use path-based authz on our
repository.  If *any* translation team wants to use branches and tags for
their efforts, that's *totally fine*.  We want to *encourage* productivity,
not be a hinderance to it.

Yes, the repository layout has been somewhat English-centric, but in some
ways that makes sense -- the English book is what is being translated.  That
said, if there is some other layout that would make everyone happy, let's go
for it!  What did you have in mind?  Something like:

   www/
   en/trunk
      tags
      branches
   es/trunk
      tags
      branches
   ...

?  Where do you put the shared build system?  Use svn:externals?

> Another consequence of this is that current tags and branches (from
> repository root) have useless snapshots of incomplete translating
> efforts that really make no sense. English branches and tags should
> had been that, english only.

Tags and branches in Subversion are dirt cheap to create, and our naming
convention has been to include the interested locale in the tag/branch name:
 'en-1.5-final', 'zh-1.1-final', etc.  Who cares of those directories
contain unfinished work?  How is this any different than branching, say, the
Subversion source code repository's trunk *right now* to go off and
implement a new feature?  The branch certainly begins life with
half-implemented features like tree conflicts (which are still under active
development in the trunk), but that doesn't prevent the branch from being a
useful place to develop some other unrelated feature.  Even there we use
branch names like 'fs-rep-sharing' or 'wc-ng' so that folks know that the
focus of the branch is "just the FS layer code" or "just the working copy
layer code".

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




More information about the svnbook-dev mailing list