Subversion, and moving mousepad in?

[Auke Kok]

Brian J. Tarricone wrote:

> Jasper Huijsmans wrote:
>
>> Olivier Fourdan wrote:
>>
>>> On Wed, 2005-03-02 at 13:49 -0800, Brian J. Tarricone wrote:
>>>
>>>> I'm still in favor of having a toplevel xfce4/ module for the core 
>>>> components, if nothing else than to make it easier for people to 
>>>> just check out all the core stuff and nothing but the core stuff.  
>>>> Unless I'm missing something and that either doesn't really make it 
>>>> easier, or is a pain to set up properly.  I don't really feel 
>>>> strongly about it, so I'll just go with what you think is best, 
>>>> since you have much more svn experience than I do.
>>>
>>>
>>> ditto. Plus svn is easy on move, so moving parts from/to the core will
>>> be easy.
>>> I don't have strong feelings either, but it sounds like a nice idea.
>>>
>> Again, just a feeling, but the xfce4/ toplevel for core components 
>> sounds useful to me, especially for casual browsing of the tree. In 
>> the same way I'd like to see a plugins/ toplevel as well, that is, if 
>> and when we decide to move over plugins from berlios.
>
>
> I retract my request for this.  Apparently keeping a subdir will just 
> complicate matters, and we can make a pseudo-folder to hold the core 
> components for convenience.  Or something like that.  Judging by 
> #xfce-dev scrollback, Benny's geting a bit testy about this whole 
> subject, so I think it's probably safest if we just bow to his 
> apparently-superior wisdom here. 


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 think method 1 would be a good start, but in the future might not 
prove workable as permissions become more and more complex (and anyone 
could possibly write to the repository directly).

Method 2 reduces the overhead and still gives proper base permissions, 
protecting e.g. the core apps (even if not grouped) against writing by 
goodies-maintainers. Switching parts over to use the http-auth method 
would make flexible changes very easy. I don't think moving code around 
the tree will pose a large problem (benny? anyone with better svn 
knowledge?). I strongly this choice.

Method 1 and 2 also allow read-only checkouts using the http method (so 
you get anonsvn for free, if wanted). This therefore isn't a factor in 
the choice.

Method 3 would mean much more work to set things up initially, and using 
a whole different auth method+passwd administration. Given the fact that 
all the repositories need to be converted, I think for now that it's out 
of the question.


If anyone is handy with cvs2svn I'd propose he/she comes forward about 
it. If not then I need to run some tests myself before the weekend. A 
list of repos is also needed.

Auke