Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0-rc1
-
Component/s: maven-scm-provider-mercurial (hg)
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :12
Description
it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation.
mercurial is (currently) much faster than bzr and therefor really useable.
-
- maven-scm-hg.tar.gz
- 12/Oct/06 4:55 PM
- 20 kB
- Alain Hoang
-
- maven-scm-provider-hg.diff.gz
- 17/Sep/06 2:20 AM
- 16 kB
- THURNER rupert
-
- maven-scm-provider-hg.tar.gz
- 27/Oct/06 5:03 PM
- 19 kB
- Ryan Daum
-
- maven-scm-provider-hg.tgz
- 17/Sep/06 2:20 AM
- 18 kB
- THURNER rupert
-
- maven-scm-provider-hg-0.09.tbz
- 22/Oct/06 3:32 AM
- 67 kB
- THURNER rupert
-
- maven-scm-provider-hg-0.8.tbz
- 05/Oct/06 6:30 PM
- 19 kB
- THURNER rupert
-
- maven-scm-provider-hg-0.8.tbz
- 05/Oct/06 6:28 PM
- 46 kB
- THURNER rupert
-
- maven-scm-provider-hg-0.8.tbz
- 05/Oct/06 6:27 PM
- 46 kB
- THURNER rupert
-
- maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz
- 12/Apr/07 10:30 AM
- 19 kB
- Ryan Daum
-
- scm-230-patch-1.svndiff
- 13/Apr/07 9:19 AM
- 7 kB
- Ryan Daum
-
- site-patch
- 12/Apr/07 1:06 PM
- 4 kB
- Ryan Daum
-
- site-patch-2
- 12/Apr/07 1:14 PM
- 3 kB
- Ryan Daum
Issue Links
Activity
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.
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?
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:
{rev}\nchangeset:
{node}\n
{tags}author:
{author|escape|addbreaks|tabindent}\ndate:
{date|isodate}\ndesc:\n
{desc|strip|escape|addbreaks|tabindent}\n
{files} {file_adds} {file_dels}\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 would like to assist with the development of this plugin. I've checked out all the source I need, and used thurner's 0.09 tbz (with its hg repos), but only 2 of the unit tests pass. Is all of Alain's work patched into that version? Can somebody host an hg repository somewhere that will hold the mainline of this work?
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.
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.
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 ...
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/
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
Do you want to implement it?