Cool. I have the tarball from SourceForge. I was planning on converting the repository from CVS to SVN and rearrange it as described. Can our ops guys merge two SVN repositories? Or is that a nightmare? Is it easier if I just leave it as CVS?
Also, with regard to the 3rd party (non-ASF) DLLs (Hibernate etc.), are you physically deleting them from the repository (can you do that with SVN)? I was going to delete the ,v file from cvs entirely, so that the 3rd party jar files aren't even in history. Cheers, Clinton On Sun, 16 Jan 2005 12:14:41 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > > Can we move forward with this? > > Sure, after the CVS and SVN repositories are brought over. :) > > By then, I'll be able to confirm that tagging the individual subprojects > won't be a problem. > > I really should be tagging my own project releases, and I can start doing > that on Monday. Like iBATIS (and Struts), we are running several different > products with individual release cycles out of the same repository. We a > release schedule for tomorrow to put the latest DataMapper binaries into > production (yeah!), and I can update our repository to resemble this > structure. > > -Ted. > > On Sun, 16 Jan 2005 09:31:03 -0700, Clinton Begin wrote: > > So then, we have five +1s on the following directory structure: > > > > /branches (as required) > > /tags > > */java > > **/releases > > ***/2.1.0 > > */cs > > **/releases > > ***/1.5.0 > > /trunk > > */site > > */cs > > **/mapper > > **/dao > > **/docs > > **/npetshop > > **/tutorial > > */java > > **/mapper > > **/dao > > **/docs > > **/jpetstore > > > > With the understanding that we won't be moving DAO out just yet > > (there's a bit of effort there). > > > > Can we move forward with this? > > > > Cheers, > > Clinton > > > > On Sun, 16 Jan 2005 07:21:21 -0500, Ted Husted <[EMAIL PROTECTED]> > > wrote: > > > >> Just to recap, > >> > >> * I'd suggest that the SVN structure represent the > >> subproject/release structure, where the subprojects are > >> > >> ** java/mapper > >> ** java/dao > >> ** java/docs > >> ** java/jpetshore > >> > >> ** cs/mapper > >> ** cs/dao > >> ** cs/docs > >> ** cs/npetshop > >> ** cs/tutorial > >> > >> ** site > >> > >> If we later change the release structure, we can change the SVN > >> structure to match, since moving things around in Subversion is > >> cheap. > >> > >> * I'd suggest that we tag each subproject release before it is > >> rolled. Ideally, the tag should identify exactly what goes into a > >> given subproject release. > >> > >> * Obviously, I don't care if we keep the tags in subdirectories > >> or in a master directory at the top. My only concern is that it > >> is easy to tag only the resources that pertain to a given release. > >> > >> * I haven't done any SVN tagging myself, but someone who does > >> said it was easier to create the tags if we we used a > >> > >> /$subproject > >> ./tag > >> ./trunk > >> > >> structure. Of course, it might be just as easy to keep them all > >> at the root. I haven't had a chance to try yet. > >> > >> * If someone wants to forward this post to a SVN guru, that would > >> work for me :) > >> > >> It will be a couple of days before the repos are rolled over, and > >> we don't have to start shuffling things around right away, so > >> time is not of the essence. > >> > >> -Ted. > >
