CODEWITHSUNDEEP
svnmercurial
Knowleech
Knowleech

Reputation: 1055

read-only svn access to hg repository

Hg is fine and all, however, there are some Svn-Features we (the development team) are really missing. Most importantly:

These are two rather pressing issues, while the benefits of Hg over Svn seem more and more to be nice-to-have features. This is, because I like tools to be fit for our (established and successful) workflow instead of changing our workflow to the paradigms of the tools.

So, one idea would be to maintain a read-only svn repository clone of our hg repository. After much googleing I found that bitbucket is actually trying something like this:

https://confluence.atlassian.com/display/BITBUCKET/Using+Subversion+to+Access+a+Bitbucket+Repository

(and it seems, it does not work very well).

I am not interested in committing to the repository via svn nor do I need the full history available through svn. I just need the default tip available.

The most important repository is currently hosted on SourceForge. If this feature in BitBucket would have been working, I would not mind switching hosters. However, I do not want to maintain a server of my own (I got enough problems already).

Thus, my question is:

Does anyone know of a working solution to access a hosted Hg repository via Subversion?

The sad through is, if not, we might actually migrate back to svn.

Upvotes: 3

Views: 361

Answers (1)

Lazy Badger
Lazy Badger

Reputation: 97282

  1. AFAIK, no such (working) bridges exist - there are a lot of architectural differences in the core between hg and svn, which make "Mission impossible" (from my POV)

  2. You can think about hand-made bridge for mirroring from Mercurial to Subversion (depending from your data mainly), which have to

    • hg export tip changeset (probably in hook) to patch-file (experiment with additional options, I have not idea, which can be useful)
    • svn patch your WC with the patch from the above point

From another side, I'll suggest read, study, check and evaluate Subrepositories in Mercurial (but I'll recommend to use from the beginning GuestRepo extension, which was created in order to avoid some shortcomings in Subrepos).

This way you have not to change workflow, but have to only repositories structure under the hood: instead of using big monolithic repo for every project you use a set of smaller independent repos, which (thin) "superrepo" combines into project's repository (and subrepos will provide emulation /to some degree/ of sparse checkouts and externals from SVN-world)

Upvotes: 1

Related Questions