Using Mercurial to work with a Read-only SVN repo: merging update from trunk

I have access to an SVN repository that I can grab occasional snapshots of revisions (as .gz, not through svn update) and am hacking the code to add some customizations that I do not have any intention of pushing back to the SVN repo. I'm using mercurial to manage my local copy and have seen two wa开发者_StackOverflow中文版ys of dealing with this situations.

1. Based on the approach laid out at https://www.mercurial-scm.org/wiki/SubversionToMercurialHowto, you store the unmodified svn repo in one branch, work in the other and then update the svn and pull changes over and merge conflicts.

2. Just keep two independent repos and do a hg pull -f from the svn based clone into the working one and then merge the conflicts.

I was wondering if there was an advantage to one approach over the other, and how to deal with the fact that I can't easily update the svn copy, and instead probably have to re-write the whole repo (unless there is another way to selectively replace files that have changed).

Based on the answer to this other SO question, I'm going to say it will be better to use named branches rather than cloning because of the differences in tracking where changes came from (if that matters in your situation). Merging changes incoming from the Subversion repository with either cloning or named branches is basically the same and where the changes are coming from (SVN, your commits, etc) is also irrelevant. Mercurial will be able to handle the merges.

Also, the Svn2Hg how-to explains a method of being able to give back a unified diff to the SVN repository. So, if you're not able to commit to it, you should be able to give someone a unified diff to apply those changes you want to give back.

Lastly, if you do eventually gain access to the SVN repo, you'll want to use the hgsubversion extension which will turn Hg into a SVN client and allow you to push changes directly back to the SVN repo.