Subversion, and moving mousepad in?

[Auke Kok]

Brian J. Tarricone wrote:

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


correct.

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


Possible: I would have to allow module owners to write to their DAV 
authentication file (they can only give *https* acces, not ssh access).

Jasper can have access to everything as far as I'm concerned ;^). Unless 
we all switch to use the https auth method, there is no way for ssh 
developers to change their groups. The classical unix permission system 
simply prohibits this.

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


unless we put the core in a grouped repository, there is no way of doing 
this as far as I can see (unless svn offers some aliasing/grouping). 
This is why putting everything top-level might be cumbersome.

Since also the amount of developers working on the core is relatively 
small and stable, I think that would be a good start (grouping xfce core 
libs).

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


okay stop picking fleas. CVS has the same problems. think about it... 
we're now working in one huge repository... everyone with ssh access and 
in the xfce group can modify and commit everywhere.

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


don't blame people that they need to read e-mails and interpret properly 
then :^P

"future" refers to "perhaps as soon as immediately after we move to SVN" 
as in "next weekend".


for the record:

1. I can spend my weekend better than migrating 25 cvs trees into 
subversion BUT I really want to move to subversion on most/all of the 
projects on espresso

2. moving to subversion and taking the time to setup permissions better 
is a STEP FORWARD. it will help *YOU* since you can rely on better 
access controll to the different repositories. (I really don't care if 
you guys want a fully open repos. but it would not be my choice).

3. we can do more steps forward LATER after we migrate from CVS to SVN 
and start to use the
things that make SVN really a lot better. (first A, then B).

4. there are no steps backwards anywhere, other then you folks needing 
to learn subversion (well, I need some more experience too).


seriously... do not mistake my technical comments for negative advice 
towards SVN. I would not recommend moving to subversion otherwise! There 
are just implications that I feel you people should know... not because 
they will make stuff break etc in the future, but because you have a 
right to use this information in your decision on how to setup the new 
repositories. I'm trying to show you all sides of the technical aspect 
in the most honest way.


Auke