Subversion, and moving mousepad in?

Auke Kok sofar at
Thu Mar 3 23:14:47 CET 2005

Jasper Huijsmans wrote:

> Brian J. Tarricone wrote:
>> Ok, this complicates things.
>> Auke Kok wrote:
>>> technical comments coming up, please read carefully as they will 
>>> influence the future layout:
>>> options available:
>>> 1. make one huge svn archive
>>> (    a. everything under its own tree
>>>     b. some things under a separate tree (core, plugins?)   )
>>> - pro: you can move everything everywhere
>>> - con: access control is hard: requires subversions pre-hook hack to 
>>> separate people in groups, then assigning them writeable space
>>> 2. make one svn repo per tree (module) (either grouping core or not)
>>> - com: moving is hard: you're physically moving between different 
>>> repos (although as far as I understand it's possible without problems).
>>> - pro: fine-grained access is easy (same way we do cvs perms at the 
>>> moment)
>>> 3. use http auth / webdav method
>>> - pro: huge fine-grained control possible
>>> - con: large overhead on permission administration
>>> - con: security (not using ssh)
>> I'm not a big fan of #1 if it means that fine-grained permissions 
>> will be hard.  I think #2 makes good sense - we rarely need to move 
>> files between modules.  After we figure out exactly what will go 
>> where, there probably won't be much of a need to do this.  #3 seems 
>> to really suck on the security front.  Is there no security at all?  
>> WebDAV works over SSL, right?

works ALSO under SSL. If I'm gonna permit http commits it will be httpS 
only (plain http is too simple for this)

>> I think we're looking at this the wrong way.  We need to come up with 
>> a list of requirements, and then figure out which setup best fits 
>> those requirements.  Here's my first stab at such a list:
>> * Flexible permissions.  We want to give translators access to 
>> (ideally) just their own .po files.  In the common case, this will 
>> mean restricting each translator to one file per module.

very hard, but possible (with https) also very horrible to setup, 
although we can make the https daemon for a group of https users work 
side-by-side with the developers over ssh as normal. The devs get full 
access, the .po translator only to his file

>> * Xfce devs should have commit access to all of the Xfce core 
>> component modules, but not other projects (xfmedia, mousepad, 
>> non-core panel plugins).  It would be nice if non-core maintainers 
>> could easily give commit access to others (that is, other people who 
>> already have commit access to other parts of the repo), but this 
>> isn't a necessity.

granting access is a matter of requesting it from me. there's no 
automated way of doing this. The webform for new devs however makes it 
about 2 minutes of work for me for a new developer.

>> * Ability to group components.  It would be useful to be able to 
>> designate certain modules (e.g., libxfcegui4, xfwm4, xfce4-panel, 
>> etc.) as "core Xfce components", and be able to check out/update 
>> based on that.  Basically I want an equivalent to "cvs co xfce4" 
>> which grabs the core without getting, e.g. xfmedia.
basic unix gid's cover this the way we handle this now. works fine I think

>> * Ability to branch/tag some modules without touching the others.  
>> Related to this, the ability to tag/branch a series of modules (e.g., 
>> Xfce core) without having to issue a dozen commands and do each one 
>> individually.

err... for module in a b c ?

>> * Easy file renames/moves within modules.
svn move libs/something.c obsolete/old-something.c && svn ci

>> * CVS-like operation.  If we can't do everything with svn that we 
>> already do with CVS, what's the point?

the move trick is one reason. https access is another, but I really like 
to begin without it. In the future we can extend access with the https 
methods for more flexibility (like adding a whole new auth layer for 
devs that do not have a ssh account).

trust me... you want that ;^)

> Being able to do grouping is important to me too. That would be much 
> harder with separate repos, wouldn't it?

again, basic unix GID's cover this pretty okay (you're not gonna ask me 
to make 200 submodules every weekend... (I wish too))

> I certainly don't want to impose a big administration burden on Auke.

hence my proposal to start with svn+ssh first. Later we can take baby 
steps into https/svn and I'll throw in webmail for free.


More information about the Xfce4-dev mailing list