CODEWITHSUNDEEP
mercurialrevision-history
Evert
Evert

Reputation: 593

"linking" revisions of two repositories

We are in a situation where we have one "general modules" repository which is shared between different project repositories. The problem we face is that if you go back to an earlier version of a project, we cannot really know which "general modules" revision has been used with this project. We could check the date and time stamp and see if they match, but there must be another more elegant way to do this. The general modules repository doesn't change as frequently as the projects itself. My question is: how do you deal with this and what are the best practices?

Upvotes: 1

Views: 79

Answers (2)

Reimer Behrends
Reimer Behrends

Reputation: 8720

Aside from using subrepositories etc., another option is to use a tool like Peru, which makes repository synchronization either an explicit manual operation or can be used as part of the build process. This is particularly useful if you need to integrate with repositories outside your organization, ones that use a different VCS (or none at all), etc.

Upvotes: 1

Nanhydrin
Nanhydrin

Reputation: 4472

I think there are a couple of options for what you're after, although I think both will only help for the future and can't really fix up your past history.

Subrepositories

Subrepos are the original Mercurial solution to your issue.
You clone the general modules repo into your main project working copy and update its working copy to the revision you want to use.
Then you set up a .hgsub file which tells the main project that it has a subrepo, where it should go and where the source of it is.
Then when you commit the main project the .hgsub is committed and the hash of the general modules working copy is saved into the revision in a .hgsubstate file.

However there are issues with them,

  • recursive commits and pushes, which may not be desirable;
  • they can be difficult to understand and therefore a source of errors;
  • if you move the source repo your updates will fail, although there is a subpaths config option that gets around this.

Here's a good walkthrough on using subrepos.

Guest repos

I've never used these so I can't comment on their pros or cons or even their use but here is a link to the Guest Repos Extension. I think the idea is that it's more fault tolerant than the subrepo setup, so if the guest repo source is missing or the changeset specified is missing it's easier to fix.

I've also seen references to nested repos, as a slightly different thing to guest repos, but I'm not sure if they genuinely are different things.

Upvotes: 4

Related Questions