On Sun, 21 Mar 2004, Craig R. McClanahan wrote: > Quoting Martin Cooper <[EMAIL PROTECTED]>: > > > On Sun, 21 Mar 2004, Ted Husted wrote: > > > > > On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: > > > > Option 1 works for me. Simplest thing that could possibly work. As > > > > you've said, we can always change things around later. > > > > > > The problem is that is that we already have the simplest thing. And, if we > > want multiple Maven-based products with independent release cycles, then what > > we have won't work. :) > > > > We already have the simplest thing in terms of one repo, but we have far > > from the simplest thing when it comes to organising within that repo. The > > point I was trying to make with (1) is to distinguish between organising > > using multiple repos versus organising within one repo. > > > > For example, if we do what you suggest below, and have 7 separate CVS > > repos, we will face a number of problems, as I see it: > > > > a) We will not make friends with the infrastructure folks. Each time we > > add a new committer, they will have to add 7 separate avail entries with > > that account. > > > > That turns out not to be the case, for at least two reasons: > > * A single "avail" line can be attached to multiple repositories > (as is already true, for example, for Tomcat's multiple repos). > > * Infrastructure needn't be bothered with CVS karma issues anyway ... > lots of folks (including me) can do that edit directly. > > > b) People will need to do 7 separate 'cvs update' invocations to get all > > of the latest code. That just doesn't seem practical to me. > > > > At work our CVS admins have set up aliases so you can do a single "cvs co" or > "cvs update" on an alias and get them all at once. Don't know how that works > with IDEs that interact, but it certainly works sweetly from the command line.
Ah, yes, I'd forgotten all about modules in CVS. It's been quite some time since I've used those. > > > c) It's not clear to me that the Maven reactor could be made to work > > across multiple repos. And even if it could, which repo would the Maven > > files live in? > > > > I plead clueless on the Maven-related aspects of this, but have seen that the > Geronimo folks seem to have a pretty good multi-subproject setup going (albeit > from a single repository). > > > d) Any multi-repo build would have to make assumptions about the location > > of the other repos on the local disk. It would be reasonable to assume > > that they are peers within the same directory, but that is an assumption > > that we would have to make. > > > > e) Web site maintenance is going to be, um, challenging. We would actually > > need an 8th repo for site-wide documentation, and then we'd need to have > > some tools to avoid having to do 8 separate 'cvs update' invocations to > > update the entire site on www. > > > > I think we should rip the website stuff out of the webapps anyway. Sounds good to me. > > > f) Any time we want to add something new (e.g. opt-foo or core2), we would > > need to go back to infrastructure and ask for yet another repo. > > > > Nope ... just an additional name on the "avail" list, something that I (or > anyone else with cvsadmin karma) can do. More than just an avail entry, I would think. It would at least need a new directory under CVSROOT. But I can see that any cvs admin could do what's needed. > > > I see little advantage of all those separate repos over just one repo, > > since that one repo could be organised in exactly the same way. In other > > words, why use separate repos over something like this: > > > > struts/ > > core/ > > taglib/ > > app/ > > opt-legacy/ > > opt-el/ > > opt-faces/ > > opt-sandbox/ > > site/ > > > > or even this: > > > > struts/ > > core/ > > taglib/ > > app/ > > opt/ > > legacy/ > > el/ > > faces/ > > sandbox/ > > site/ > > > > Actually, I'm not sure that a sandbox should be under 'opt' at all. I > > could see us using a separate repo for that, since there is precedent in > > both Commons and Taglibs. > > > > I am now leaning towards 3 repos myself: > > > > struts-legacy > > This is our current repo, renamed. I don't really care for this > > name, but I can't think of anything better right now, and I hate > > sticking numbers in repo names, because they become invalid > > quite rapidly if they are associated with versions (unless we > > start a new repo for each major version, a la Tomcat, but I > > don't like that idea either, for CVS history reasons). > > struts > > This would be structured per one of the suggestions above. > > struts-sandbox > > A separate sandbox, a la Commons and Taglibs. > > > > The reason I've changed my mind since yesterday about 2 repos versus 1 > > (ignoring the sandbox for the moment) is that I realised that all of the > > CVS shuffling we want to do will make it very hard, if not impossible, to > > continue to work on older (pre-shuffle) versions of the product. > > > > One other minor comment: I'd prefer to use something like 'archive' over > > 'legacy', since the latter has a more negative connotation, in my mind at > > least. But I won't make a big deal of it if other people prefer 'legacy'. > > ;-) > > > > I'd be happy with either the seven approach or the three approach. As you've > concluded, I don't see how we can gracefully refactor and continue to work on > the old code with only one. Maybe "struts-original" has better connotations? Yes, 'original' sounds a little better. ;-) > I'm also very willing to defer any decision to migrate to SVN ... CVS, for all > its warts, sounds like it still offers everything we need at the moment. Agreed. -- Martin Cooper > > > -- > > Martin Cooper > > Craig > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
