mercurial - several projects and repositories

70 views Asked by At

(disclaimer: I am completely new to mercurial and version control)

So I have a folder structure

Programs
  CPPLib1
  CPPProject11
  CPPProject12

  CPPLib2
  CPPProject21
  CPPProject22

Each group of three is completely independent of the other group, but within each group the code is related and I'd like to manage it under version control as a whole (commit/extract everything in one transaction). As I understood by googling it, I must have a repository for each group in their common parent (Programs), but I cannot have 2 different repositories there, right? Does it mean I must have this structure instead:

Programs
  Group1
    CPPLib1
    CPPProject11
    CPPProject12

  Group2
    CPPLib2
    CPPProject21
    CPPProject22

A related question, this site http://help.fogcreek.com/8169/using-more-than-one-repository says

"Since Mercurial and Git are Distributed Version Control Systems (DVCSs), you should use at least use one separate repository per project, including shared projects and libraries."

So what does this advice mean? I can't have a separate repository for each of

  CPPLib1
  CPPProject11
  CPPProject12

and manage them as a whole. I am confused.

1

There are 1 answers

1
planetmaker On

For each of you project groups you'll need to create one repository in a separate directory. On how you structure that beneath is up to debate and depends a bit on your preferences.

You say that you want everything in that project group managed within a single repository. It means you can simply create a directory structure as you described with the sub-projects residing in different directories within this repository.

Within each group, you can take it further and make each of these directories (library, programme 1, programme 2, ...) a separate repository which in turn become a sub-repository to the main repository, as described in the link given by Lasse Karlsen (Subrepository).

You could also handle it differently, if you allow a more flexible layout and let go of checking out one group in its entirety: For instance you could declare the libraries a sub-repository to each of the programmes which uses the library. It would have the advantage that the programme defines this way directly which library version it depends on

Further, before jumping to sub-repositories, you might want to look at the alternative implementation of guest repositories as well. They handle the dependency less strict, thus a failure to find the sub-repository becomes less fatal: https://bitbucket.org/selinc/guestrepo