Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later.
Steve > -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: March 20, 2004 9:44 PM > To: Struts Developers List > Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status > > > On Sat, 20 Mar 2004, Craig R. McClanahan wrote: > > > Quoting Joe Germuska <[EMAIL PROTECTED]>: > > > > > At 2:48 PM -0500 3/14/04, Ted Husted wrote: > > > >I'd say we could branch what we have as 1.2 and start thinking of > > > >the HEAD as 1.3. > > > > > > > >IMHO, the quickest way to sort out what we need to do with the > > > >Struts-Chain RequestProcessor is to get it out there as > the nightly > > > >build. [Many hands make light work ;)] > > > > > > > >So, we could reserve the 1.2 for any desperate fixes (as > we've done > > > >before), but do anything resembling new development > against the HEAD > > > >(1.3). > > > > > > I might do something like this over the weekend, > depending on my time > > > (then again, I may not at all!) > > > > > > But if I did, I'd want to see if anyone had any strong > feelings, or > > > fixes they thought they'd like to get in before a branch, or... ? > > > > > > Or should all of this wait until we get the move to > struts.apache.org > > > settled? I'm assuming we'll reorganize CVS as part of that, into > > > struts-core, struts-taglib, etc... > > > > I think there's a lot of merit in rationalizing the > directory structures as part > > of the move to TLP-ness. > > Assuming we don't move to Subversion right now (see other thread), the > move is effectively a CVS repo rename by the infrastructure > folks, lock, > stock and barrel. Any rationalisation is totally up to us. > > If we want to break up our existing repo, we have a couple of options: > > 1) One top-level 'struts' repo that we break down as we see fit. This > option leaves everything in our control, since, as far as > infrastructure@ > is concerned, there is only one CVS repo. > > 2) Multiple top-level repos, one of which is a renamed version of our > current repo, and the remainder of which are new empty repos. We would > then migrate pieces of our current repo out to the new repos. > > 3) Same as (2) above, except that we don't ask for a repo > rename, but just > new repos, and we migrate everything ourselves to the appropriate new > repo. > > While (3) is the "cleanest" insofar as we wouldn't have > leftovers in the > Attic of the renames repo, it's also a huge amount of work for us, and > runs the risk of forgetting things. > > My preference is for (1). It is the simplest approach, and > will allow us > to move things around however we see fit, without having to decide up > front which other repos we might want. If, at some point, we > decide we do > want other top-level repos, we can request them at that time. > > > > Speaking of that, can we/should > > > we do anything to preserve CVS logs if we move files? Or will we > > > start fresh? I think if we move the actual CVS files it > will all be > > > preserved, but I've never tried that. > > > > > > > There are ways to preserve history, but I suspect there > will be difficulties if > > we decide to split up what has been a single repository > (jakarta-struts) into > > per-subpackage repositories. A guru on CVS would > definitely be useful here. > > A CVS repo rename will preserve all of our history, > obviously. After that, > I can take care of preserving history whatever we decide to > do (as long as > we stay with CVS ;). It's slightly easier if we have only one > repo, but it > can still be done across repos. > > -- > Martin Cooper > > > > > > > I'm interested in getting the Struts Chain stuff mainstreamed, but > > > like I said, this may very well not be the weekend I > start on it. In > > > any case, I figured a branch would be cause for a little bit of > > > discussion amongst committers. > > > > > > > I'm going to focus some energy as well on commons-chain and > struts-chain now > > that JavaServer Faces is done. > > > > > Joe > > > > Craig > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
