Subversion, and moving mousepad in?

[Brian J. Tarricone]

Auke Kok wrote:

> Jasper Huijsmans wrote:
>
>> Brian J. Tarricone wrote:
>
>>>
>>> * 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

Ok, so that's only possible with https.  Am I correct in assuming that 
the only way we're going to be able to give translators/non-devs (i.e., 
people without real accounts on espresso) commit access is via https?

>>> * 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.

For full shell access, of course.  But assuming we eventually implement 
something else on top of svn (https/webdav?), would it be possible for 
individual developers to be designated as "owning" a module such that 
they can give commit access to others?  Say, like, someone started 
sending me a string of crazy-awesome patches for xfmedia and I 
eventually decided to give him/her commit access.  Would I be able to do 
that - and only that - on my own?  I'm getting at the case where it 
would be useful to add people who maybe shouldn't get a full account on 
espresso.  Also consider the case if I wanted to give, e.g., Jasper 
xfmedia commit access (who already has access to another part of the repo).

>>> * 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

Not sure what you mean here.  How does setting group ownership on the 
files create a logical grouping of modules that I can see without having 
access to the svn repo's filesystem?  Right now, we have instructions on 
the website to tell users how to check out Xfce CVS.  It's a one-liner.  
I don't want that to become:

$ svn [whatever] libxfce4util
$ svn [whatever] libxfcegui4
... etc.

And posting a for loop to get them all sounds silly to me.

>>>
>>> * 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 ?

Sure.  If you want to have to constantly remember which modules are in 
Xfce.  Which I don't.

>>> * 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 ;^)

Right.  But frankly, the main benefit I see to svn at this point *is* 
the https access and the ability to do fine-grained permissions for 
translators and whatnot.  CVS is far from the best solution in the 
world, but I don't think we've had too many problems with it such that 
moving away from it is actually necessary - it would just make a few 
more things possible, and maybe a few things easier.  If we're taking 
steps backwards in other areas, I start to question the wisdom of this 
switch.

>> 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.

Certainly - I don't want to impose either.  Hence my offer to donate 
some time to help with initial setup.

    -brian