How can I add Mercurial support to Stash?

[Richard]

Hi, I'm exploring options. We use Mercurial, but want to be able to use Stash. There are a variety of options I'm looking at (including hg-git plugin for mercurial), but one of these options is adding support directly to Stash for Mercurial.

Now, I've created a module that implements ScmService. And I had (I had hoped) configured the module such that my implementation would be available to the dependency injection mechanism, in the hopes that it would get picked up instead of the default implementation in Stash. Either I've done it wrong, or this isn't possible (using *ahem* normal paths).

My next idea is to just blow open the Stash impl jar and replace PluginScmService with my own implementation. Evil, but not the worst thing I've ever done.

Is there supposed to be a way to replace the default implementation of various Atlassion interfaces, or is evil my only hope?

[Daniel Wester · Accepted solution]

I don't think it will be as easy as just swapping out ScmService. You're basically talking about taking out the guts of Stash and putting in your own engine. Might be possible but I suspect that there will be more to it than just switching out a couple of classes. You'll also have to handle the hg connections at the top of my head - but the worst thing would be any internal code that's hiding assuming having access to "gitness" - I know that there are plugins that assuming that they have access to run git commands for example(I've got a couple).

With each release you'd also have to do a full regression test to make sure things didn't break (including the patch releases).

If you can - I would suggest staying away from it becaue of the testing headache. The hg-git plugin sounds like an interesting approach though.

[Richard]

Here is the error I've been getting with hg-git:

rbair$ hg clone git://rbair@localhost/scm/rt/master.git
destination directory: master
abort: nodename nor servname provided, or not known

[Richard]

I tried hg-git first. There's actually two modes -- one is that the "real" repo hosted by stash is a git repo, and you setup hg-git locally on your own machine and it lets you talk to a git repo as it were an hg repo. Except when I tried to do so against my locally installed stash, it didn't work, I kept getting odd errors (I can list them here if you like in a bit as I'm about to reproduce that setup again).

The other way which I also tried was to dig around in the stash instance and swap out the git repo with an hg repo, and then use hg-git to create the .git metadata directory. In theory this is supposed to allow a git client to talk to a mercurial client as if it were git, but with huge caveats.

I also found this link (http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/) which contains some tools for having a git repo talk to an hg repo as if it were git. From what I can tell though, really all this does is allow a git client to clone a remote hg repo and push / pull to / from it (much like hg-git). That's great, but not really very useful in this case because there is no remote repo as far as Stash is concerned. So I think I'm stymied there.

It does raise an interesting possibility for the Stash developers though. Instead of having to update their codebase to talk to Mercurial or Git, perhaps they can keep focused on Git primarily and perform the mapping from git->hg on the lower level (i.e. by using git commands that end up working against an hg repo).

For example maybe for hg support Stash coudl end up having two local repos -- a git repo and an hg repo. The git repo would forward changesets to the hg repo and vice versa?

Not many good options.

[jhinch _Atlassian_]

Stash does not support the git protocol so git:// will not work. You need to use http:// or ssh://

[Richard]

That actually was the first thing I tried (just grab the url Stash gave me and plugged it in):

rbair$ hg clone http://rbair@localhost/scm/rt/master.git
abort: HTTP Error 501: Not Implemented

I grabbed the latest version of hg-git (https://bitbucket.org/durin42/hg-git/overview) and the latest (.0.9.0) of Dulwich (https://pypi.python.org/pypi/dulwich).

I had read that hg-git didn't support http, but added it somewhere recently, however my attempts so far haven't worked out. I don't know how hg-git handles the git protocol and had half assumed it used it as a way to determine to invoke the git support (instead of trying to do a normal hg clone) and would transpose to http behind the scenes -- but maybe not.

[Stefan Saasen]

Hi Richard,

Another wild idea is to have an implementation of git that actually just called hg commands for everything -- thin wrappers. Maybe if built on top of mq? I'm not that familiar with git, but I've read that other than branching everything pretty well maps.

Our intergration is much deeper than this. We not only use low-level git commands (for example to traverse the commit graph or to diff trees) but directly access the objects in the git object store to resolve information we need. Any wrapper would be far from thin and your simplified usage of git wouldn't change that.

via pull requests

I think this is a good example why this will be incredibly difficult to implement. There is a fair amount of finesse in the implementation of pull requests (think about moving pull request comments when updates on a branch change the lines where comments are anchored) that is hard to replicate.

Furthermore, for any large organisation performance of the repository hosting is important and we spend a fair amount of engineering time to get this right (and we are always improving this) that is very specific to the underlying VCS.

From a political perspective inside our team, being able to say "we have here our normal hg repos and stash just works against it" is a much easier sell than "we have to change our master repos to be git repos, but you can still use hg if you want to on your own system by using this plugin".

I can understand where you are coming from but trying to implement this from the outside is going to be like trying to push rope up a wall. It's going to be very time consuming and difficult and you will end up with a Stash snowflake that will be very hard to upgrade and maintain and won't be supported by the vendor.

So unfortunately I can't give you an easy way to do this and can only strongly suggest that you don't go down this path :)

Cheers,

Stefan

[Richard]

Stefan thanks for the pointers. I actually don't have the sources but was just poking around with javap hoping to find who was implementing ScmService and replace that piece! I'll take this advice and try to get the hg-git route to work first.

From a political perspective inside our team, being able to say "we have here our normal hg repos and stash just works against it" is a much easier sell than "we have to change our master repos to be git repos, but you can still use hg if you want to on your own system by using this plugin".

Another wild idea is to have an implementation of git that actually just called hg commands for everything -- thin wrappers. Maybe if built on top of mq? I'm not that familiar with git, but I've read that other than branching everything pretty well maps. And branching is OK if you stick to bookmarks on the mercurial side (at least, this appears to be the claim on hg-git) and void Octopus merges.

From a policy perspective the way we would be using git would be very simple. The main master repo and the various team repos have *no* branches at all. The individual developer repos could have branches, but since those don't ever get merged up directly (but rather, via pull requests) I'm thinking that our usage pattern is simplistic enough that a naive mapping between git & hg would work for us.

[Stefan Saasen]

Hi Richard,

There is no need to replace the PluginScmService - on the contrary, that service allows you to plug other scm implementations into Stash (e.g. see ScmModuleDescriptor). The current git implementation (a plugin) might be a better starting point but please read my the following caveat first before you get started.

I would advise against going down the path of implementing Mercurial support in Stash on your own. Although we built the scm layer with pluggability in mind we have only one implementation at the moment so it is entirely possible that the abstraction isn't a 100% complete and we haven't (and don't) test for this at the moment. Furthermore plugins (external but potentially internal as well) might make assumptions about the underlying scm that would break Stash functionality.

Instead of trying to work around this from your end with a lot of testing required when we release new versions of Stash you should consider other options (e.g the above mentioned hg-git plugin).

Cheers,

Stefan