mercurial plugin

Do you want to implement it?

if you would be so kind to point me to the bzr provider source code, i'll have a look.

found it in the maven faq and with a little clicking up and down in the svn tree:
http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-providers/maven-scm-provider-bazaar/

it would be nice if the maven scm project site would state this more prominently

first implementation try - svn diff file. created in mvn-scm toplevel dir.

hg-scm provider, the files tared.

current state is experimental. work is derived from the bzr provider.

half of the tests fail. i guess the main reason is that the tests try to get an "inventory", and i don't know how to get that with mercurial ... as i always use it the other way round: what is NOT in the inventory. everything else would be.

you have a hint how to solve / avoid this issue?

from the mailing list:

revno is either id or parents or tip
inventory is either manifest or locate

I've been hacking on the 'experimental' tarball for a week or so now. I've been able to get more tests to pass however there are actually some semantic differences between bzr and mercurial that make this not as simple as find and replace on the class names to get running.

Just fixing 'inventory' won't fix all of the problems. (I already did with locate)

In terms of functionality, I think it works mostly but the unit tests are failing due to different semantics between mercurial and bzr. Noteably:
1. Mercurial's understanding of URLs is not the same as bzr's. For example you don't specify file:/// to reference repositories on the local filesystem.
2. The diff format is closer to subversion's diff format than the one that bzr spits out.
3. The log format is not the same

I've been trying to get these to pass the unit tests but it requires rewriting quite a few of the unit tests so that it passes mercurial's notions of the tests. I'll try to post an updated tarball as soon as I can.

for a log output similar to bzr one could use

hg log --style changelog.tmpl -l 1

with changelog.tmpl:

changeset = 'rev:

\nchangeset:

\n

author:

\ndate:

\ndesc:\n

\n

\n'
start_tags = 'tags:'
tag = '\t

\n'
start_files = 'modified:\n'
file = '

\n'
start_file_adds = 'added:\n'
file_add = '

\n'
start_file_adds = 'removed:\n'
file_del = '

\n'

(as suggested by http://www.selenic.com/pipermail/mercurial/2006-May/008349.html)

now less tests fail ... especially i threw out the "file:///".

the other two points mentioned by alan are still missing.

and i'm wondering if we should try to use source code control, so one gets the changes of the other?

emmanuel? are you reading this?

this time after doing a "mvn clean".

could somebody more powerful throw away all the other source files?

My current work in progress. Have not had time to continue working on this lately.

I've uploaded my current work. I'm afraid I've not had time really work on it lately.

If people are interested I can try hosting the provider plugin in a hg repository to make colloboraton easier until this gets merged into the main svn tree

1. created mercurial rep (so the zip contains a .hg as well)
2. applied (some of) alains patches
3. removed some of the assertions

I have done some work and put a branch of thurner's repository up at:

http://darksleep.com/~ryan/maven-scm-provider-hg.cgi

I made changes so that all tests but 3 pass. One of these failures is related to the diff format as noted above.

The other one, I cannot see an easy way to resolve, as it is part of the Scm tests packaged with Maven SCM itself. Basically, the test tries to add an empty directory, then expects to see a status result saying "added" for the directory addition. Hg knows nothing of directories, just the files in them, so the hg command returns 0 for the # of files in the status results. The test then fails. The only thing I can think to do is make the add command "lie" for empty directory additions, but this is so hacky I fear it. Perhaps the CVS SCM plugin has some ideas I can pilfer.

Sorry for being so spammy, but I just added the above kludge to fake addition for empty directories. Now the remaining problems are log and diff file format as mentioned by Alain above.

I have made all the unit tests pass, except one (HgCheckoutCommandTest), which has some heisenbug which causes it to fail inconsistently. Running it in the debugger and putting breakpoints in... causes it to pass. "mvn test" succeeds about 50% of the time.

Found the source of the problem. It is in HgChangeLogCommandTckTest, and is actually a problem in the last test in the base ChangeLogCommandTckTest. Basically it checks in two revisions then tries, using date/time filtering to retrieve only the later one. This may work fine for slow network based revision control systems, but for Mercurial, the creation of the file and its checkin happens within the same second, so the log reports the same time for creation of both revisions, and nothing fits within the date filter range. In some cases, if the checkin happens of the second file happens to occur after the second value of the date increments, the test passes.

I am unable to fix this, it is IMHO a defect in the base ChangeLogCommandTckTest.

Completion of the passing of all Hg SCM provider tests relies on a fix to SCM-244.

If you want the test to pass now. It might be possible to override ChangeLongCommandTckTest to perform the behavior that you want with a huge caveat and link to the issues at hand. This should work as a workaround until upstream decides what they want to do with this test.

While working on the Mercurial plugin I found a couple of other crappy assumptions in the TckTest Suite which caused me some aggravation.

I will give SCM-244 a few days to gel, and see if anybody looks like they'll move on it. If not, I may do as you say.

I am new to the Maven community, and do not know how I would go about getting the Mercurial plugin included in the Maven 2 distribution, and also if it's permissible to just get SVN access and fix the ChangeLongCommandTckTest base class myself. Any ideas? The company I work for is making use of Mercurial, as well as Maven, and I want to be able to use Continuum and other features of Maven that rely on SCM support.

upload a patch and mailbomb scm-dev@maven.apache.org mailing list

i wonder also if there is a place to document the testcases so that people need not to "reverse engineer" them by codereading. some poeple prefer a top-down approach ...

btw, thanks a lot for the fixes! we also have this problem.

The latest maven-scm-provider-hg after all my recent work (all but 1 unit tests pass).

Initial version of the maven-scm-provider-hg has been commit'd to http://svn.apache.org/repos/asf/maven/scm/trunk/sandbox/maven-scm-provider-hg/

What happened to the above SVN repository? Where can I find the latest hg scm provider sources? Is there any chance that this will ever make it into the main Maven 2 build?

it is in maven sandbox : http://svn.apache.org/repos/asf/maven/sandbox/scm/maven-scm-provider-hg/
I'll look at it if we can move it in maven-scm trunk

I've attached a patch to dependent issue SCM-244 which fixes the one remaining test that was failing maven-scm-provider-hg

Since I don't have check-in priviledges, and I've done work to bring this provider up to spec with the current 1.0-SNAPSHOT maven-scm API that is on trunk, I am attaching a tarball for someeone else (Emmanuel?) to check into Subversion.

Please integrate this provider; passes all tests.

Can you provide a patch for the site?

Sure. Attaching.

I also have a slight modification to the existing HgScmProvider which I will add as a patch once the initial version is checked in (so I have something to do the diff against.)

Oops, there was a problem with the last patch in the way it created the new mercurial.apt

Here's new and improved

Applied. Thanks

Please find attached a patch which fixes the following issues:

1. Allow file/http/https URLs for checkout
2. Fix bug where checkout would only work while inside an existing repository
3. IntelliJ IDEA project file was accidently checked in.