Haha...if you want, a friend of mine just wrote a Subversion book. We can consult him for advice. :-)
But for now, here's mine: First, what is trunk, tags and branches? In Subversion, they're just copies. Nothing more. None of them actually has any meaning. For the most part, they're just recommended naming conventions for the *root* directory structure of a repository. >> distributions with their own releases, then I think >> it'll be easier to work with releases (and their matching >> tags) that way... It won't make a bit of difference. It's just an extra directory level. > Then a tag like mapper_1_5_0 would be created from /trunk/cs/mapper in this Given the global nature of revision numbers, we should always tag the entire repository anyway. I guess the question is: do we have one repository, or many? If we have one, we should tag the whole thing (Java/.NET whatever). Tags are practically free, and they won't conflict. So there's no need to worry about the redundancy. Tags are also less important in SVN, and they're really just copies (as is a branch --no difference). > looking through a list of combined Java > and .NET tags. > + 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? There's no reason why you couldn't organize your tags regardless of your project directory structure. In fact, it's even better this way. Because no assumptions have been made about your project structure, your tags are free to be organized indepenedntly of it. Of course, you could _only_copy the .NET resources if you really want. You could easily have: /tags ./java_releases ../2.0.9 .../java ../2.1.0 .../java ./net_releases ../1.0.1 .../cs ../1.4.8 .../cs **IMPORTANT** I will ask the opposite question of you. If you have this structure (multiple trunks): /cs ./trunk /java ./trunk /site ./trunk **THEN** How do you create a project-wide tag of the entire repository? You can't. Not without a completely ridiculous end result of this: /tags ./project_milestones ../some_big_event_we_are_proud_of .../cs ..../trunk .../java ..../trunk .../site ..../trunk That's nasty --trunk directories in a project wide tag. We're one project. We should have one trunk. Best regards, Clinton On Sun, 16 Jan 2005 00:32:26 -0500, roberto <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > > > >
