pull over HTTP hangs despite having credentials in [auth] section

Issue #3 open
Arthur Blake
created an issue

JavaHg seems to be working fine with commands that just access the local repo, but when I try and pull in remote changes (on a repo that requires authentication for all access), javaHg prints errors, and then no further commands work, saying "Trying to execute new command when command already running" (until I kill the process.) It does seem to work properly when the remote repo does not require auth for pull, incoming.

Example program that causes the problem for me: {{{


package whatever;

import java.io.; import java.util.; import com.aragost.javahg.; import com.aragost.javahg.commands.;

public class HgPullTest { public static void main(String[] args) throws IOException { System.setProperty("com.aragost.javahg.hgbin","C:\Program Files\TortoiseHg\hg.exe"); Repository repo = Repository.open(new File("C:\sites\admin\clones\prod\latest")); printChanges(PullCommand.on(repo).execute()); repo.close(); } public static void printChanges(List<Changeset> changes) { if (changes == null) { System.out.println("no changes!"); } else { for (Changeset change: changes) { System.out.println(change.getRevision() + " " + change.getUser() + " " + change.getMessage()); } } } }





SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. From HG: unknown exception encountered, please report by visiting From HG: http://mercurial.selenic.com/wiki/BugTracker From HG: Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] From HG: Mercurial Distributed SCM (version 2.0.2) From HG: ** Extensions loaded: javahg From HG: Traceback (most recent call last): From HG: File "hg", line 42, in <module> From HG: File "mercurial\dispatch.pyo", line 27, in run From HG: File "mercurial\dispatch.pyo", line 64, in dispatch From HG: File "mercurial\dispatch.pyo", line 87, in _runcatch From HG: File "mercurial\dispatch.pyo", line 684, in _dispatch From HG: File "mercurial\dispatch.pyo", line 466, in runcommand From HG: File "mercurial\dispatch.pyo", line 738, in _runcommand From HG: File "mercurial\dispatch.pyo", line 692, in checkargs From HG: File "mercurial\dispatch.pyo", line 681, in <lambda> From HG: File "mercurial\util.pyo", line 458, in check From HG: File "mercurial\commands.pyo", line 4959, in serve From HG: File "mercurial\commandserver.pyo", line 230, in serve From HG: File "mercurial\commandserver.pyo", line 210, in serveone From HG: File "mercurial\commandserver.pyo", line 193, in runcommand From HG: File "mercurial\dispatch.pyo", line 64, in dispatch From HG: File "mercurial\dispatch.pyo", line 209, in _runcatch From HG: File "mercurial\ui.pyo", line 625, in warn From HG: File "mercurial\ui.pyo", line 468, in write_err From HG: File "mercurial\commandserver.pyo", line 39, in write From HG: File "mercurial\windows.pyo", line 64, in write From HG: ValueError: I/O operation on closed file


Comments (19)

  1. aragost Trifork repo owner
    • changed status to open

    Yeah, I'm not surprised to hear that. We need to add code for authentication against both HTTP(S) and SSH servers. I'm pretty sure the code will be different for those two cases since the Mercurial code paths are very different:

    • HTTPS: Mercurial is prompting you internally. That should be available in the command server and so be relatively easy to handle
    • SSH: Mercurial starts your ssh binary and that will prompt you for username and password as needed. My thinking is that we can handle this by shipping our own ssh replacement (there must be a Java SSH library we can use for this) and configure Mercurial to call that instead of the normal ssh program. Before that, we should look into how MercurialEclipse and NetBeans handle this case.
  2. Arthur Blake reporter

    When I run hg pull or incoming on that repository from the command line it does not prompt me for the user & password because I have them entered into my .hgrc file. I would have thought that the command server would honor those same local settings and just work properly...

  3. Jan Sorensen

    The reason the server doesn't use your .hgrc file is because the server is started with env var HGRCPATH set to the empty string. This is to avoid that your personal configuration would change the behavior of Mercurial in such a way that JavaHg is unable to parse the output.

    @martin: Isn't this what HGPLAIN is for? We do set HGPLAIN, is there any reason also to set HGRCPATH?

  4. Jan Sorensen

    I tried to removed the HGRCPATH (in Server#execHg(...)) which means the server will run with my personal .hgrc. Then a few testcases fails, it is because I have configured some merge tools that changes the output of the merge command. I suggest that we make it configurable what .hgrc file to use (none, Mercurial's default, or explicit path), and I would prefer to be conservative and have 'none' as default. It would probably be implemented as a property on RepositoryConfiguration. What do you think about this? If you enable a hgrc file it is your responsibility to ensure that command output is unchanged, if not JavaHg might not work.

    It could also be made more advanced and only use some "whitelisted" sections from the hgrc. It is easy to extract sections with the 'hg showconfig' command.

  5. Jan Sorensen

    I have implemented the above suggestion. Hope you like it :-) The RepositoryConfiguration has now a hgrcPath property that if not null will be used as the value to the env var HGRCPATH.

  6. Martin Geisler

    @Jan Sorensen: It's a bit unclear what the exact semantics of HGPLAIN is. But as I understand it, the general idea is that HGPLAIN will reset [defaults], [alias], ui.verbose, and other settings that might change the output of core commands.

    Extensions are not disabled by HGPLAIN. Some of them might want to react to HGPLAIN: color, pager, and patchbomb does this.

    I think we disable HGRCPATH to get complete control over the execution. That way JavaHg becomes the sole interface to Mercurial: applications using JavaHg need to configure everything but can then also expect to get repeatable results.

    I'm a bit torn here: on one hand it's very clean to let JavaHg handle everything, on the other hand it is a little surprising that PullCommand doesn't just use the credentials from the [auth] section.

    I think the question is if the PullCommand in JavaHg is a thin front-end for hg pull? If so, then executing it should do exactly the same as running hg pull. Or is PullCommand a front-end for the more general concept of pulling changesets in Mercurial? If so, then it would be okay for us to deviate from the behavior or hg pull and require people to set passwords "manually" in JavaHg. Manually might mean calling a copyAuth method to get the [auth] section from the user's config file.

  7. Mallikarjuna

    After these changes I am getting the following error

    java.lang.RuntimeException: abort: error: _ssl.c:504: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

    at com.aragost.javahg.internals.Server.execHgCommand(Server.java:523)
    at com.aragost.javahg.internals.Server.cloneMercurialRepository(Server.java:513)

    But I can able to clone in command line.

    How to fix this ?

  8. Log in to comment