Disclaimer: (always nice to see this as the first thing in an email!) I am not a source control guru! :-)
---------------------------------------- It looks bad to have trunks everywhere, but if the DAO and Mapper libraries are going to be distinct distributions with their own releases, then I think it'll be easier to work with releases (and their matching tags) that way... If the .NET code had a release and the SVN structure was like: /trunk /cs /java /site /tags /mapper_1_5_0 (something like this) /java_2_1_0 Then a tag like mapper_1_5_0 would be created from /trunk/cs/mapper in this case instead of basically from /trunk since the .NET release wouldn't need the Java code. Or the tag would still be from the /trunk but not include the /trunk/java dirs, just /trunk/cs/mapper. I think I prefer tag contents originating from the trunk, so I like Ted's suggestion for the trunk locations. This way, I can go into /cs/mapper, find the /tags dir and grab whatever tag I needed (for a specific release let's say) instead of theoretically looking through a list of combined Java and .NET tags. I guess one way to figure this out is to see: + How would you like to have your tags created/named/organized in the tags folder? + What should each tag contain (in terms of files)? + From what top-level folder should the files for the tag come from or be copied from? That should probably determine where the trunk(s) need to be located and the process for creating tags (releases) and their contents after the move. Roberto > -----Original Message----- > From: Clinton Begin [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 15, 2005 11:42 PM > To: roberto > Cc: ibatis-dev@incubator.apache.org > Subject: Re: ASF TODO [short] (was ASF TODO [long]) > > This is what I really don't like....multiple trunk folders is horrendous. > > # /java > # * ./core (SQL Maps) > # ** ../trunk > # * ./dao > # ** ../trunk > # * ./docs > # ** ../trunk > # * ./jpetstore (we can just commit the latest version) > # ** ../trunk > > The root of the repos should (IMHO) be: > > /branches (as required) > /tags (as required) > /trunk > ./java > ../mapper > ../dao > ../docs > ../jpetstore > > There's no need to split it up at a project level in the root, nor is > there any reason to have multiple trunks. > > Cheers, > Clinton > > > On Sat, 15 Jan 2005 23:35:54 -0500, roberto <[EMAIL PROTECTED]> wrote: > > > > > > > > Clinton, I think Ted updated his suggested dir structure in the Wiki > Roadmap > > page: > > > > > > > > http://wiki.apache.org/ibatis/Roadmap > > > > > > > > The final structure (after some intermediate structure he has also > proposed > > due to the move) is a little similar to yours with the diffs being: > > > > > > > > . the location of the branches/tags directories (created as > needed) > > > > . the trunk dir (each subdir has its own) > > > > . the docs dirs (one each in Java and .NET/C# subdir) > > > > . and the 2 *PetS* dirs (one each in Java and .NET/C# subdir) > > > > > > > > I'm pasting in that proposed final structure and some of his text into > this > > email so it's quicker to see for other folks on this email list: > > > > > > > > > > > > > > So, the root folders are > > /cs > > /java > > /site > > > > Of these, /java and /cs each have subfolders. Each of the subfolders > have > > their own trunk. > > /java > > * /core > > * /dao > > * /docs > > * /jpetshore > > /cs > > * /core > > * /dao > > * /docs > > * /npetshop > > * /tutorial > > > > The /site folder has the Forrest sources for the website, and it's own > > /trunk > > > > Any folder that needs a tags folder (or branches folder) can create one > as > > needed. But there's no point in creating one until it's needed. > > > > > > > > > > > > > > Roberto > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Clinton Begin [mailto:[EMAIL PROTECTED] > > > > > Sent: Saturday, January 15, 2005 11:11 PM > > > > > To: ibatis-dev@incubator.apache.org > > > > > Subject: Re: ASF TODO [short] (was ASF TODO [long]) > > > > > > > > > > -1 On SVN directory structure > > > > > > > > > > Oops, I don't like the idea of having multiple /tags and /trunk > > > > > directories. I really don't see the advantage, and it may just make > > > > > the repository harder to browse. I don't like calling the root > > > > > directory of the project "Source", because we have more than source > > > > > within a project structure, as well as the fact that there is another > > > > > source directory below that. I don't like "/Source/iBatisJava/src/", > > > > > which is what we'd end up with (both redundancy and contradictory). > > > > > I'd rather stick with the more traditional approach, and keep the root > > > > > of the trunk at a "project" level (not referring to project artifacts > > > > > like "source"). So I'd suggest something like this: > > > > > > > > > > /branches > > > > > /tags > > > > > /trunk > > > > > ./iBatisNet > > > > > ./NPetShop > > > > > ./iBatisJava > > > > > ../ibatis-1 > > > > > ../ibatis-2 > > > > > ./JPetStore > > > > > ../jpetstore-1 > > > > > ../jpetstore-2 > > > > > ../jpetstore-3 > > > > > ../jpetstore-4 > > > > > ./site > > > > > ./documentation > > > > > ../tutorial > > > > > ../devguide > > > > > > > > > > +1 on separating DAO (later) > > > > > > > > > > This shouldn't be an issue to do this later. I've always wanted to do > > > > > this, but never had the motivation. :-) This could either happen > > > > > below the .NET and Java source directories if we still considered them > > > > > part of the same project, or we could rename iBatisNet and iBatisJava > > > > > to NetMapper and JavaMapper respectively. Then introduce NetDAO and > > > > > JavaDAO (or whatever) later. These points are less important because > > > > > SVN makes our lives somewhat easy in this respect. More important is > > > > > the previous discussion of the root of the repository. > > > > > > > > > > +1 on the removal of 3rd party (non-ASF) libraries. > > > > > > > > > > I'll remove all non-ASF libraries tomorrow and write devsrc code for > > > > > them (like I did for TopLink). > > > > > > > > > > Cheers, > > > > > Clinton > > > > > > > > >
