I would just suggest tagging the trunk (make a copy of trunk with a well-defined name in the tags folder), and do whatever you want to do with the trunk, it's supposed to be the current development line. In addition, I would suggest, adjusting the published docs to point to this tag to check out the infrastructure. However, if there's any plan on continued maintenance, then create a branch, tag off that, point the docs to check out the tag.
If we're not very sure about this "2.0" code, then I would create a branch for it "2.0-dev", then once it's ready, tag the trunk as 1.0 and then merge(replace?) the 2.0 code into the trunk. This is exactly what 'branches' sub-folders are for, maintenance and disruptive (to the trunk) current development. It seems silly to create a pseudo-branch under the trunk folder, as the whole point of the branches/tags/trunk folder is for working like this. If we don't want to work like that, then dump the whole convention. Let's stop avoiding good SCM practices and embrace them. In the case of buildtest, just work with the caveat that "releases" are directly checked out, instead of downloaded from an alternate location. -Nathan On 4/23/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
Hi, I'd like to give an update about current status of buildtest infra. Currently we have the proposal [1] for the infra improvement, its implementation [2] and several testing suites that use the proposed approach. I think that the proposed infra is not quite ready to do the switch - I've reviewed the implementation and tried 4 suites with it; I've found several issues and I see some places where it can be improved. And I believe that the issues should be resolved before switching to the new testing infra. To make further progress I think it makes sense to commit the implementation from [2] to SVN as it is. And continue development and bug fixing in SVN. This will make improvement process more transparent, for example, currently there is tenth version of 'btinfra.zip' file and it is not possible to figure out what have changed since its first version. I'm not sure that a new branch should be created to check in the new infra. I think it may be acceptable to create sub-directory in trunk, say 'v2.0'. And continue the infra development and new suites integration there. After we find that the new infra in a good shape we can do the switch. Opinions? [1] http://mail-archives.apache.org/mod_mbox/harmony-dev/200703.mbox/[EMAIL PROTECTED] [2] http://issues.apache.org/jira/browse/HARMONY-3501 Thanks, Stepan Mishura Intel Enterprise Solutions Software Division
