title: CVS virtual modules & directory mapping to mercurial repositories
body: <p>My question is similar to <a href="https://stackoverflow.com/questions/1233052/migrating-from-cvsnt-to-subversion-whats-the-equivalent-of-virtual-modules">this one</a> but for Mercurial (converting using <code>cvs2hg</code>). However there some differences. This is part of our <code>CVSROOT/modules</code> file and shows the problem nicely:</p>
  
  <pre><code>PD1 -a PROD/PD1/Drivers Drivers/PD1/Firmware KernelHeaders Shared IppLibs
  PD2 -a PROD/PD2/ Drivers/PD1 KernelHeaders Shared IppLibs
  
  #PD2Linux Driver
  PD2Linux PROD/PD2/Drivers/Linux/BuildFiles &amp;PD2LinuxSource
  PD2LinuxSource -d src &amp;PD2 &amp;PD2LibUSB
  PD2LibUSB -d ThirdParty/libusb libusb
  </code></pre>
  
  <p>As you can see the driver structure is complicated. We're definatly looking to rationalise the driver structure, rather than including the entire older driver (PD1) in the newer one.</p>
  
  <p>As I understand it, in Mercurial you can use the share extension to do the sub directory mapping.</p>
  
  <p>My questions are </p>
  
  <ul>
  <li>Is there a way in Mercurial to bring files located further down in the directory tree (in this case the autoconf files) upto the root as is done in the first line of the PD2Linux Driver?</li>
  <li>Is there a way to create directories, as per the <code>-d</code> flag?</li>
  <li>How to merge changesets that span PD1 &amp; PD2?
  
  <ul>
  <li>e.g. if changes were made in PD2 that spanned both drivers and checked in to PD in CVS. This is bit of long shot as CVS doesn't have changesets. </li>
  <li>I wonder if the <code>cvs2hg</code> takes into account the CVS modules file?</li>
  </ul></li>
  <li>Atm I converting each PD directory individually (creating a cvsroot in each subdir), would it better so convert them all together and then split up them into seperate hg repos?</li>
  </ul>