Subversion, and moving mousepad in?
Brian J. Tarricone
bjt23 at cornell.edu
Fri Mar 4 00:21:17 CET 2005
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
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
>> 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.
More information about the Xfce4-dev