On Tue, 2008-02-19 at 22:29 +0100, Endre Stølsvik wrote: > Upayavira wrote: > > Justin put it very well in a related thread elsewhere (permission > > sought): > > [ CHOP interesting adamant view from Justin ] > (Where is "elsewhere", btw?)
Apache has a number of "internal" lists on which members communicate amongst themselves regarding the organisation and operation of the Foundation. > What I find strange in all this is the view that ALL projects at Apache > would have to change to OtherSCM if one project would want that.. (a) we couldn't manage it otherwise, purely in terms of volunteer time (b) we would have a disjoint set of the Foundation's core asset, which might be acceptable temporarily, but would not as an ongoing situation. > Indeed, I find the decision to use one single SVN repo for the entire > organization's source pretty strange. I'd believe that one repo for > every TLP, for example, would be great (AFAIK, TLP-promotion can be > handled too with history preserved). This would help in every single > aspect in regard to the volume of source and activity, could use > multiple servers etc - and incidentally using another SCM for a > particular project wouldn't be that big a deal anymore. The only > downside I see is a slight bit more configuration management, and that > copying/moving a file from one repo to another would not keep history > that well. How often does this happen, though? > However, I'm no SVN expert, so I can easily have misunderstood > everything. The thing is, that we're working with an order of magnitude more complexity here. Setting up a wiki, you'd think that was relatively simple task. However, once we'd set up MoinMoin wiki, we found it couldn't handle the traffic, and entered upon a 2 month hacking bonanza to get some kind of caching in front of it so that it would actually stay up and respond in reasonable time. And that was only one of the issues. We had similar issues in the early days of SVN, and we would hve similar issues in the early days of _any_ new piece of technology that is introduced here. That is why infra folks are resistant - they have, by direct experience, knowledge of what it is like to change this kind of stuff. HTH. Upayavira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
