[Tickets #5284] Re: Move to subversion for Horde code repository

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=5284
-----------------------------------------------------------------------
 Ticket             | 5284
 Updated By         | Jan Schneider <jan at horde.org>
 Summary            | Move to subversion for Horde code repository
 Queue              | Horde.org Servers
 Type               | Enhancement
 State              | Assigned
 Priority           | 2. Medium
 Owners             | Horde Developers
-----------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2007-11-02 04:04) wrote:

>> If possible we should try to also run it on http://svn.horde.org. I
>> guess we don't need the svn root folder for svn access and can use
>> some mod_rewrite or similar magic to correctly redirect requests to
>> either svn or chora. If not possible, svnweb.horde.org should work
>> too.
>
> I'm not sure what we would rewrite on? We could do something like 
> http://svn.horde.org -> Chora; http://svn.horde.org/repository -> 
> readonly dav_svn, https://svn.horde.org/repository - developer 
> dav_svn. We just couldn't then put something named "repository" into 
> the top level of svn. :) Suggestions for something other than 
> "repository" are fine by me too, but that's probably the way to go.

I'm not sure it this would work out of the box or if we need some
rewriting rules for that. If it works, even better!

> One more thing to consider: do we want to keep the structure ported 
> from cvs, with a single trunk and global tags and branches 
> directories? Or do we want one set of trunk/tags/branches per 
> project? Keeping the existing structure is simplest, and while it's a 
> lot easier to move stuff around with svn, it's not *completely* free 
> (still grows the repository a bit).

I can see advantages on both approaches. I guess we have to collect some
pros and cons, especially technical ones. Separate projects sounds nice,
but since we copy/move code around between projects from time to time, I
can see having all in one (svn) project making more sense.
But it's more important whether one of these setups makes it easier to
checkout one (horde) module inside another.