Satpal
Satpal

Reputation: 309

CVS virtual modules & directory mapping to mercurial repositories

My question is similar to this one but for Mercurial (converting using cvs2hg). However there some differences. This is part of our CVSROOT/modules file and shows the problem nicely:

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 &PD2LinuxSource
PD2LinuxSource -d src &PD2 &PD2LibUSB
PD2LibUSB -d ThirdParty/libusb libusb

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.

As I understand it, in Mercurial you can use the share extension to do the sub directory mapping.

My questions are

Upvotes: 1

Views: 272

Answers (1)

Martin Geisler
Martin Geisler

Reputation: 73788

You write:

As I understand it, in Mercurial you can use the share extension to do the sub directory mapping.

Not quite. The share extension let's you associate several working copies with a single repository — it's not about remapping (sub-)directories.

  • 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?

The answer to this and your other questions is: no. The core problem is that Mercurial (and other distributed version control tools) requires you to checkout the full repository every time. You cannot just clone repo/some/dir/, you must always clone repo/.

  • 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?

The end result should be separate Mercurial repositories — precisely because you need to clone the full repository. So make sure to make a 1–1 mapping between repositories and your drivers.

One tool that you might find useful is subrepositories. A subrepository is a nested repository that Mercurial will checkout when you clone the outer repository. The come with a number of caveats, but big companies are using them today (I've helped a number of companies with setting up subrepos).

Upvotes: 1

Related Questions