0

I have what seems to be a unique situation. I need to have a central Mercurial repository that can pull from a Subversion server and whose clones will also be able to pull updates from the same Subversion server. The updates would be committed to the Mercurial repository along with changes committed via Mercurial.

Now, hgsubversion seems to work well at first, cloning the Subversion repository, allowing me to commit changes via Mercurial, and correctly pulling updates from the Subversion repository. However, when I clone the hgsubversion repository, the clone attempts to pull the entire Subversion repository all over again, despite it already being in the repository.

Is there a way to fix this problem? Is there a better way to set this up?

For reference, my current setup is a Subversion repository stored within a Mercurial repository. Mercurial commits also commit the .svn folder, so anyone cloning the repository can simply run SVN Cleanup on the folder and then SVN Update to get the latest files from the Subversion server. They then run hg Commit followed by pushing the files to the central Mercurial repository. This works moderately well, but I'd prefer to find a better solution.

Note: I don't need to push changes back to the Subversion server. I only need to pull changes.

Josh
  • 632
  • 7
  • 13

2 Answers2

0

Central server (even in Mercurial) is CENTRAL SERVER. If it cloned Subversion repo and have pull cycle why clients repeat this operation? It's wasted time... But it can't break anything, because

my current setup is a Subversion repository stored within a Mercurial repository.

Is just wrong. Not "not elegant", "ineffective", "error-prone", but - WRONG!!!

Mercurial clone of Subversion repo (with hgsubversion) is Mercurial classic repo, which have Subversion in externals (in [paths] as one of targets) and some link-specific metadata.

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Sorry, I don't understand your answer. The cloned hgsubversion repository pulling the entire SVN repository again, revision by revision, is no small amount of time lost, _and_ it results in a _huge_ new head. This is not acceptable for what we are doing. The central repository correctly pulls only the revisions needed. I need this behavior with clones of the repository as well. – Josh Dec 14 '12 at 00:34
  • Also, though I sympathize with your response to the SVN/Mercurial setup, it is the only solution that I have found that addresses what I need: the ability to clone a Mercurial repository that can also pull from an SVN repository. The Mercurial clone _must_ be able to pull from the SVN repository. If you have a better solution to this, I'm very open to suggestions. – Josh Dec 14 '12 at 00:40
  • @Josh - OK, I'll test your setup some time later (have to work on my favorite galleys now). But I still don't understand two things: 1. why you (want to) pull SVN-repo from clones, *if* svn-revisions already are on central Mercurial repo, which is default target on all clones 2. Where you see "SVN-repo within Mercurial repo" - when you communicate with SVN over hgsubversion, result of initial clone is **Mercurial repo**. [Interacting with Subversion](http://mercurial.aragost.com/kick-start/en/hgsubversion/) from aragost Trifork's "Mercurial Kick Start" is useful reading – Lazy Badger Dec 14 '12 at 03:20
  • Ah, allow me to clarify. My current setup does _not_ use hgsubversion but instead only a Subversion repository within a Mercurial repository. I'm attempting to set up hgsubversion as a (much better) alternative, but it's currently giving me the problem I've detailed here (it attempts to repull every revision made instead of only the ones since the last pull--but only when pulling from clones). – Josh Dec 14 '12 at 07:37
  • As to the reason... Honestly, on consideration, I'm not entirely certain. Currently our setup is to clone the central repository and pull SVN updates from the clones, then push the updates to the central repository. But...really, it probably would be best to set up hgsubversion on the central repository and update that. My biggest concern there being that if something went wrong, the main repository would be lost. I feel it's likely safer to pull the SVN update from a clone (via hgsubversion, preferably) and then push to the central, but...maybe not? – Josh Dec 14 '12 at 07:45
0

Apparently this is answered in "hg help subversion":

When interacting with Subversion, hgsubversion relies on information
about the previously converted changesets. This information will not be
updated if pushing or pulling converted changesets to or from any other
source. To regenerate the stored metadata, run "hg svn rebuildmeta
[URI]". This must also be done if any converted changesets are ever
removed from the repository.

Using "hg svn rebuildmeta [URI]" worked perfectly to solve the problem of clones not properly pulling new revisions.

Josh
  • 632
  • 7
  • 13