7

I am using mercurial on my project.

Now I face following problem: I have two separate mercurial repositories with their own history. Now I need to have identical branches/bookmarks for both of them.

But this leads to lots of potential problems:

  • somebody merged first repo and forgot do same for second
  • created a bookmark and propagated it only on second repository

So I've thought that using mercurial subrepos will do the trick and I can do it. But I've figured out that this is not the case.

Another alternative will be just put second repository in same folder with first one. But then I will loose history for second repo. And this way is ugly actually.

Are there way to solve my problem within mercurial?

So now I'm really considering to switch to git, because AFAIK mercurial cannot bear it. Please prove that i'm wrong

  • Why do you think you won't face this problem with git? – acelent Jun 28 '16 at 23:02
  • @acelent there are subtree's concept - and I think this is what I need. – Igor Konoplyanko Jun 29 '16 at 8:05
  • have the two repos ever had a common ancestor? or are they completely unrelated (until now)? – jk. Aug 10 '16 at 21:04
  • also what do you want history to look like afterwards? – jk. Aug 10 '16 at 21:06
  • They are related in term that one depends on another. If something was changed in repo A - related changes should be done on repo. for example API change – Igor Konoplyanko Aug 11 '16 at 9:07
1

In Mercurial, a second, related repository behaves very much like a branch, and takes about the same effort to manage. For example, many projects have a stable branch that must be eventually updated regarding default.

In your case, designate one of the repositories as the merge point, and use one of it working directories to pull and push from the other repository in an orderly manner.

To make it easier, you can create an alias for the second repository in the working directory's .hg/hgrc:

[paths]
default = ssh://hg@bitbucket.org/apalala/grako
remote = ssh://localhost/backups/grako

Now you can use:

$ hg incoming remote

To know the updates done solely in the remote repository.

$ hg outgoing remote

To know the changes to be exported.

To merge:

$ hg pull
$ hg update
$ hg pull remote
$ hg merge
$ hg push
$ hg push remote

The problem remains that if the same files in the same branches are being changed against both repositories, then merge conflicts are bound to occur. But the same happens against a single repository if branching is not used appropriately.

Currently, to solve the above problem, many teams require that every related set of commits belongs to a branch that can be reviewed and merged selectively. If you apply this practice, then merges in the selected working directory can be done on a branch-by-branch basis to two or more repositories.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.