atom feed17 messages in org.apache.struts.devRe: Repository Reorg (Once More With ...
FromSent OnAttachments
Craig McClanahanJul 17, 2004 2:56 pm 
Martin CooperJul 17, 2004 5:06 pm 
Vic CekvenichJul 17, 2004 6:30 pm 
Ted HustedJul 18, 2004 5:51 am 
Ted HustedJul 18, 2004 5:59 am 
Ted HustedJul 18, 2004 6:01 am 
Craig McClanahanJul 18, 2004 1:15 pm 
Ted HustedJul 19, 2004 4:24 pm 
Craig McClanahanJul 19, 2004 4:48 pm 
Ted HustedJul 19, 2004 5:04 pm 
Martin CooperJul 19, 2004 9:06 pm 
Martin CooperJul 19, 2004 9:12 pm 
Martin CooperJul 19, 2004 9:21 pm 
Ted HustedJul 20, 2004 3:52 am 
Ted HustedJul 20, 2004 5:15 am 
Niall PembertonJul 20, 2004 6:52 am 
Craig McClanahanJul 20, 2004 7:48 am 
Subject:Re: Repository Reorg (Once More With Feeling)
From:Martin Cooper (mfnc@gmail.com)
Date:Jul 19, 2004 9:06:52 pm
List:org.apache.struts.dev

On Mon, 19 Jul 2004 20:05:14 -0400, Ted Husted <hus@apache.org> wrote:

On Mon, 19 Jul 2004 16:48:35 -0700, Craig McClanahan wrote:

�I was just following the usual conventions in the Subversion book, �and am not attached to the location ("svn move" and "svn copy" are * �sweet*). �But first, a question ... if we are thinking about �actually keeping the end result, wouldn't it make just as much �sense to do the real work on Apache's svn server?

At this point, I was thinking of drafting what we were going to do on the
private server, and once we were sure it was what we wanted, then do it "once
more with feeling" on the Apache SVN server. [Things always go *much* faster the
second time around :)] Or, maybe even just get a tarball of the end-result and
hand that over to infrastructure@.

This (the former) is what I was thinking, too. When we're ready to roll, we can have infra@ create an SVN repo and cvs2svn our existing repo over to that, and then make the changes we know we want to make to get us in shape for 2.0.

One important question, though: Where are we doing 1.2.x development / maintenance? Are we leaving that in CVS and splitting off a new SVN repo for 2.0 development, or are we converting to SVN lock, stock and barrel?

I can see pros and cons to both approaches, although I think the balance tips in favour of the lock, stock and barrel approach.

But, if everyone is ready to have at it, we could just ask infrastructure@ for a
SVN repository now and be done with it. I'm always ready to cut to the chase. :)

There's no harm in going ahead and getting the SVN repo set up now, whether or not we continue to play in our playground prior to making sweeping changes in the new repo. All we need to decide is whether or not CVS is in the state we want it in for the switchover. Once it is, we'll just want to label that point and freeze checkins until the SVN repo is ready.

I'm happy to work with Fitz and the other infra@ folks to get our SVN repo up and running once we've decided what we want to do.

-Ted.