See intermixed.
On Sun, 26 Sep 2004 11:48:46 -0700 (PDT), Martin Cooper <[EMAIL PROTECTED]> wrote: > There are a couple of things that I think we need to decide on before we > make the final conversion of our repository to Subversion. They fall under > the headings of "what" and "where". > > 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*'). > I don't know what the "first" and "firstRelease" tags are, or remember why the non-upper-case branches were created. > 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. Why do simple tags (as opposed to branch tags) cost anything to keep? In CVS (at least), they don't require any duplicated storage. Does the conversion to SVN turn them (effectively) into branches? > 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. What happens to the SVN equivalent to "cvs log" when you drop stuff like this? If you lose the history of *all* changes to the files, then it would probably be better just to snapshot the current trunk (which implicitly eliminates all the old branches and tags), and just keep the old CVS repo around (in read only mode). Partial history transfer would be much worse, IMHO, than no history transfer. > 3) Drop the 'upload_1' tag and the 'upload' branch, which are related to > the original now-obsolete multipart request handling. Don't have any problem with this, unless it removes data from the file histories (see above). > 4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric feels we > should keep them. These are related to when Tiles was under 'contrib'. Same. > > 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 When we were playing around with the test SVN repository, it took me less than an hour to refactor just the stuff that would go into a struts core distribution -- and it was possible to do this without losing any file history. You can even refactor with "copy" instead of "move" if you want to maintain the old structure as well (although I wouldn't recommend that). Therefore, I'm +1 on migrating to SVN before refactoring, and -0 on waiting any longer to migrate while we try to predict what the revised organization should be ahead of time. Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
