WHAT TO CONVERT
A default "whole enchilada" conversion of the Struts CVS repo will consume about 1GB of disk space with almost 200,000 files and over 65,000 folders. Much of this is, IMHO, stuff that we are extremely unlikely to ever want. For example, this includes the following tags:
first firstRelease start STRUTS_0_5 STRUTS_1_0 STRUTS_1_0_1 STRUTS_1_0_2 STRUTS_1_0_B1 STRUTS_1_0_B2 STRUTS_1_0_B3 STRUTS_1_1 STRUTS_1_1_B1 STRUTS_1_1_B2 STRUTS_1_1_B3 STRUTS_1_1_RC1 STRUTS_1_1_RC2 STRUTS_1_2_0 STRUTS_1_2_1 STRUTS_1_2_2 STRUTS_1_2_3 STRUTS_1_2_4 upload_1
and the following branches:
Cedric jakarta jakarta-struts jakarta-struts-chain STRUTS_1_0_BRANCH STRUTS_1_1_BRANCH STRUTS_PRE_1_0 upload
This is a lot of stuff! Also, I'm hoping someone else (Craig?) knows what all of this is, because I don't know what any of the non-upper-case tags or branches are (other than 'start' and 'upload*').
My proposal is this:
1) Drop all Beta and Release Candidate tags. I just don't see why we would ever need to access those from Subversion.
2) Drop 1.2.x tags prior to 1.2.4, for the same reason as above. I don't feel as strongly about this as about (1), so if others feel that we should keep these due to their recent nature, I wouldn't object.
3) Drop the 'upload_1' tag and the 'upload' branch, which are related to the original now-obsolete multipart request handling.
4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric feels we should keep them. These are related to when Tiles was under 'contrib'.
We could also drop other tags and branches, but I myself wouldn't feel comfortable doing so unless we know what they are first. ;-}
One point to note here is that the CVS repository will still exist after the Subversion conversion. It just will no longer be writeable.
WHERE TO CONVERT
This question comes up because we know we want to restructure the repo into multiple independently releasable units. By default, the conversion will give us one 'trunk' directory with the same contents as a checkout from CVS does today.
A message from Henri Yandell on the Jakarta General list got me looking at what other projects have done in Subversion. You can see that here:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN
There seem to be a number of different approaches. For the most part, I believe we could go with the default and change things around later if we need to. The one exception looks to be if we want to go with what the 'incubator' and 'portals' projects (amongst others) have done.
In these projects, there are multiple directories under the root - and in some cases, multiple levels - each of which eventually has its own set of trunk, tags, branches directories. I don't know enough about Subversion to know all of the advantages and disadvantages of going this route. However, it strikes me that it makes the higher level directories (sub-projects) somewhat more self-contained, and allows them to retain their own sets of branches and tags, independent of the others. On the other hand, it would make it harder to tag the entire project, if we ever wanted to do that.
If we want to go with the 'incubator' style, then I think we'd need to convert our CVS repo into a directory one level down from the top of the new SVN repo, which is why I brought all this up.
On both of these topics, input from people with more Subversion experience than I have would be much appreciated. Of course, input from everyone is welcome too! This is an important decision for us.
-- Martin Cooper
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
