Add support for mercurial DVCS

[mbezjak]

Mercurial is very similar to git, so I based HgVcsSupport.java on existing GitVcsSupport.java.

I tried all relevant pride commands (update, reinit, remove, list, do, export). Everything works as expected (rebasing, pull + update, activating, etc.).

However, this is still a work in progress. I'd still like to:

• [x] create integration tests for hg that use pride from cmdline (like user would); this should test:
  • [x] pride init
  • [x] clone without mirror
  • [x] clone with mirror
  • [x] update module when it's clean (--no-repo-cache)
  • [x] update module when it's clean (--use-repo-cache)
  • [x] update module when it's dirty
  • [x] update module when it has unpublished commits
  • [x] update module when it has merge conflicts
  • [x] pride do -- hg status should work as expected
  • [x] pride list should work as expected
  • [x] remove code duplications (e.g. writing to .hg/hgrc)
• [x] squash all those commits into one (to remove useless commits)
• [x] mention mercurial in README.md

[lptr]

This is great. For the integration tests you can use AbstractIntegrationSpec. You might want to add some relevant cases to the existing integration tests. For example, PrideInitIntegrationTest could add a Mercurial module as well. hg should be installed on Travis CI, so you don't need anything extra there.

[mbezjak]

Done!

Mercurial support works as expected. The only thing I had to change is RepoCache to handle unrelated repos. Everything else is based on GitVcsSupport.

Tests cover most of HgVcsSupport functionality:

• with and without repo cache
• pristine repo, with uncommitted changes, with unpublished changes
• running pride: init, update, list, do -- hg status

In addition, those tests should also be fairly readable.

Tomorrow, I'll rebase and squash all those commits to just one. Afterwards, if you have no objections, I'd consider that to be merge-worthy.

Comments welcome.

[mbezjak]

Rebased and squashed, but I just remembered that I should mention mercurial in README.md. I'll do that tomorrow.

[mbezjak]

Done. Good to merge, I think.

[lptr]

Hey. Thanks. I'm currently not able to check this out more thoroughly, but next week I will. On Wed, 21 Oct 2015 at 11:12, Miro Bezjak notifications@github.com wrote:

Done. Good to merge, I think.

— Reply to this email directly or view it on GitHub https://github.com/prezi/pride/pull/158#issuecomment-149829457.

Lóránt

[mbezjak]

Ok. No problem.

[mbezjak]

Thanks for the comments!

I currently have an approaching deadline for a project so I'm not sure when I'll have the time to work on this. I'll try to work 20 minutes each day. We'll see how long it'll take me.

Here is the current checklist:

• [x] revert change to dynamicDependencies
• [x] HgSupport -> HgTestSupport
• [x] HgCacheRepoTest: assert dir exists + delete in finally
• [x] ProcessUtils.executeIn should be able to return exit value when needed (hasUnpublishedChanges) (new PR)
• [ ] eliminate the need for --repo-type hg
• [ ] README.md: no longer need --repo-type hg
• [ ] prideAdd and initializePrideWithModule to AbstractIntegrationSpec
• [ ] is there a better way to handle unrelated repos?

[mbezjak]

Just to be clear. I'm waiting for #161 to be merged so I can commit what I have currently before I tackle --repo-type hg. No rush; just wanted to let you know.

I've been thinking about how to eliminate the need for --repo-type hg when doing pride add. The only thing that seems valid to me is for loop over registered *VcsSupport + clone in try/catch. The main reason for this is that just from the URL (e.g. http://repo-server/project), one cannot know if this is git or hg project. One just needs to try to clone with git. If that fails then it could be a hg project and try that. Can you think of a better solution?

[Crazyjavahacking]

Can we merge this please?

[mbezjak]

Hi all.

Since gradle 3.1 introduced composite builds, I'm no longer relying on pride. So I just wanted to let you know that I won't complete the above todos (most significant is to eliminate the need for --repo-type hg). Nevertheless, I've squashed and rebased the branch so that merge could be painless if you think that the current implementation is good enough (it has a bunch of passing tests but has a --repo-type hg quirk that does not affect git usage).

Kind regards

[rosadam]

@mbezjak thanks for the update, I will review it.