Subversion, and moving mousepad in?

[Auke Kok]

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.

sofar