Subversion, and moving mousepad in?
sofar at lunar-linux.org
Thu Mar 3 10:41:03 CET 2005
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:
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
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.
More information about the Xfce4-dev