3

I read the tutorial many times and I feel that I am still missing something. I'll just try to give a concrete scenario. Please help me find where I'm wrong.

Suppose I have a repository which everyone considers as "central". This means that every new developer clones from it and pull/push from/to it. Central contains three folders-

  • Infra (which is about to be a shared code)
  • .hg
    • infra.txt
  • dev1
    • dev1.txt
    • .hgsub (in which there's a line --> infra = (path of infra) )
    • infra (subrepo)
      • .hg
      • infra.txt
  • dev2
    • dev2.txt
    • .hgsub (the same as in dev 1 - infra = (path to infra) )
    • infra (subrepo)
      • .hg
      • infra.txt

Now, suppose that one developer clones dev1, and another one clones dev2. What I see is that when the developer of dev1 changes infra and pushes the changes to the repository in central, the only way of dev2 developer to know about the change in infra is to manually search for incoming change-sets in infra as a sub-repository. Generally, It means that if my project has many sub-repositories (that may themselves contain some more sub-repositories) , I have no way to know about the changes except for going over my sub-repositories manually.

I think that's not the way to work... Can anyone help?

Thanks in advance,

Eyal

eyal.altshuler
  • 61
  • 6
  • I changed the indenting so that dev 2 is a sub folder. Is that right or should dev 2 be at the same level as dev1? It didn't seem right before, but please correct it if I got things wrong – Sam Holder Mar 11 '11 at 09:25
  • no, dev2 is another project using infra as a sub-repo. In that case, dev1 and dev2 are projects that share a library - infra. Thus dev2 should be at the same level as dev1 – eyal.altshuler Mar 11 '11 at 09:40
  • ok great. Looks better now. Wasn't sure which way it should go, but it didn't seem right at the beginning. – Sam Holder Mar 11 '11 at 09:43
  • by the way, another interesting issue is when a repository has many sub-repos. Suppose I have 50 sub-repositories in my repository, why should I pull 50 times? – eyal.altshuler Mar 11 '11 at 09:45

2 Answers2

3

I think I have found something better. You can use --subrepos flag when checking for incoming change-sets in a repository.

This will search for incoming change-sets recursively, and show us the sub-repositories in which change-sets can be pulled.

This way, one can control on which sub-repositories are changed, and whether she wants to get up-to date files in those sub-repositories.

eyal.altshuler
  • 61
  • 6
1

You are going to have to pull for each repository. You might think this tedious but there's no way mercurial is going to make the decision to pull changes into your repository for you - this is a good thing.

What you can do is create a simple batch script that runs a 'hg pull' command against each repository. That at least automates the process so it feels less tedious when you really want to pull from all repos.

We moved all our subrepos into one repository which makes it much simpler to manager a change/new feature that requires alterations to all our libraries.

I like subrepos but I think they are best suited for pulling in entire repositories that others look after that remain pretty stable. When there's a lot of changes, you need a lot of discipline and a certain amount of scripting to keep manual work down to a minimum.

Neil Trodden
  • 4,724
  • 6
  • 35
  • 55