jbossxb should be a seperate project producing a binary that is included as a binary into jboss-head. Therefore, its existence as a cvs module is not relevant. This is true of all the common module contents. The point of breaking this out was to allow reuse across projects as a binary.

The import of a single module into a svn repo is possible to do with history; however, if you are planning to import another cvs module into the subversion repo, at a later time, then you have to do something that is called interleaving.

Questions we need to answer:

Do we want a separate repository instance for each module that is contained in CVS now (i.e., common, clustering, varia, iiop, etc.)? To answer this question you have to determine whether or not you want to keep history of files, as they relate to other files in your repository, and at what time those files related. However, this may not be relevant as I think with our cvs repo, we've been moving histories via hacking the cvs files in the repo when we move between modules. This means that history, for what it's worth, will be maintained on import of that single module. If we import modules piecemeal, we have have to interleave and "change history" for the other modules that already exist in the targe repo. This is directly related to the global revision IDs.

If we are worried about how files were related to each other, historically, i.e., what did file X look like in varia, when file Y in commons was at GLOBAL revision n?, then it is better to have multiple top level projects in a single repository. If we don't care about how one file in a top level project relates to another file in another top level project at a specific revision, then we can have separate repos for each project.

Here all projects are in a single repo. This does not preclude, however, the ability of each of those projects to be top level projects--each have their own set of branches, trunk, and labels. We'll get into this more in the Branching Policy as I'm incorporating changes requested from everyone (i.e., branches/tags/trunk under each project rather than at the top level).

So, as Adrian said, it's better to do this refactoring in svn as there is no loss of history. This means, import everything at once (a single cutover for all users) and then refactor. This would mean no interleaving of any modules into a single repository (assuming we take the single repository path instead of one repository per module). If a module needs to be in its own repository (i.e., it relates in a non-critical way to other files contained in top level jbossas projects), then it is a simple process to extract it. However, importing with history, piecemeal, is more complicated and will leave people in strange states if they are working on nodes in the repository who magically have their history changed on them--a byproduct of interleaving.

The history has to correlate with the jbossas releases it was part of. However, we were not planning on moving all jbossas/jboss-head modules to svn at this pont in time so I don't see how we can have one global svn repo.

We can go ahead and do the import of common into it's own repo (for testing purposes). Once it's in there, we can take a look at the history and make sure everything is okay. Damon has requested some additional space from IT for doing this. I'll followup once the source is in place.

Scott, I'm looking at the output from when you did your build of common using maven. It shows you compiling the common-core first. You also noted that "I included all the org.jbos.util.* excluding logging in core for now. "

Did you just comment out the logging references for classes such as org.jboss.util.Base64?

Assuming you did.......

When we move xb out into its own project on svn, it will need to have as a dependency, logging. Logging classes need util classes and util classes need logging. We're not currently able to split up logging and util due to the cyclical dependency there. In this case I would build a jar from common, put it in the repo and let xb build against it?

Ok, that clears it up and I was able to break everything up in that fashion. The only piece that I don't see addressed is org.jboss.logging.util.* .

These 6 classes only depend on external dependencies (e.g. log4j). My gut feeling is that these should either be a seperate logging proj or better yet be included in with the rest of the util classes in the common-core.