On Thu, Jun 23, 2011 at 15:37, Dennis E. Hamilton <[email protected]> wrote: > The separate Hg repositories could go into separate sub-project branches if > that is more convenient for bringing them over. My sense is that once they > are in Subversion, it is relatively easy to massage them or consolidate into > a composite project tree (by SVN copying) that is where any further > adaptation and use occurs - I am assuming there are no collisions between Hg > subprojects. > > I think the bigger issue is preserving the Hg history and the different > revisions. > > Is there any agreement on how deeply we need history, is the full history > essential for provenance reasons?
Our Software Agreement gives us all the provenance that we "need". But history is best for the developers. We also see researchers using ASF repositories. People need history to understand "why" code is written a certain way. etc etc I think it would be best to combine the various Hg repositories into one, then convert that to Subversion for loading. We could probably make N subversion repositories and load those, too. For example, the main repository could construct the main trunk/tags/branches, and the CWS repositories would create /branches/CWS-1, /branches/CWS-2, etc branches. But you're going to have problems with mergeinfo and history and stuff. It is best if we can somehow link the creation of a branch as a copy from /trunk of the correct revision. Anyway. The key is to (re)construct the relationships between the groups of code. If Hg will re-link the cloned CWS repositories when they get merged, then great. I would suggest that we begin writing a document and scripts on how the merging and conversion will occur. For example, I envision that we would produce a document much like: http://cmpilato.blogspot.com/2009/11/revisionist-history.html Something that can collaboratively assembled and tested. Maybe some kind of "merge-repo.sh" script that grabs all of the various Hg repositories and assembles them into one. And then a "convert.sh" script that runs the conversion process to Subversion with all the right switches, filters, mappings, etc. I'll go even further and suggest that we can begin the above in (say) /trunk/build today. It should not be a problem to have some content in our repository. The conversion process can easily avoid stomping on it. Thankfully, we're talking about converting from Hg rather than CVS. The latter introduces nightmares that I don't even want to speak about... Cheers, -g
