dulwich-users team mailing list archive

[anatoly techtonik <techtonik@xxxxxxxxx>]

On Fri, Apr 16, 2010 at 2:57 PM, Augie Fackler <durin42@xxxxxxxxx> wrote:
>>>
>>> I'm perfectly willing to maintain a bitbucket mirror,
>>>
>>> <shameless plug> but why not just use hg-git? I do all my dulwich dev
>>> work using hg-git and it's fantastic.
>>> </shameless plug>
>>>
>>> It is not that fantastic on Windows. =) After I've fixed the issue
>>> with GitFile [1] with attached patch, it is able to successfully clone
>>> Git repository and create Hg working copy, but still fails to push
>>> with the error:
>>> abort: the remote end hung up unexpectedly
>>>
>>> I'd like to see this Windows patch integrated first to continue
>>> investigation on Windows further. It seems that there are some
>>> incompatibility issues with Mercurial 1.4.x.
>>>
>>> That's distressing. The tests get run against hg 1.4.x every time new
>>> code
>>> gets pushed. Can you be more specific?
>>
>> Latest Dulwich, latest HgGit;
>>
>>> C:\~env\Python26\Scripts\hg.bat push --trace
>>
>> *** failed to import extension progress: No module named progress
>> pushing to git://git.samba.org/jelmer/dulwich.git
>> importing Hg objects into Git
>> creating and sending data
>> Traceback (most recent call last):
>>  File "C:\~env\Python26\lib\site-packages\mercurial\dispatch.py",
>> line 46, in _runcatch
>>   return _dispatch(ui, args)
>>  File "C:\~env\Python26\lib\site-packages\mercurial\dispatch.py",
>> line 454, in _dispatch
>>   return runcommand(lui, repo, cmd, fullargs, ui, options, d)
>>  File "C:\~env\Python26\lib\site-packages\mercurial\dispatch.py",
>> line 324, in runcommand
>>   ret = _runcommand(ui, options, cmd, d)
>>  File "C:\~env\Python26\lib\site-packages\mercurial\dispatch.py",
>> line 505, in _runcommand
>>   return checkargs()
>>  File "C:\~env\Python26\lib\site-packages\mercurial\dispatch.py",
>> line 459, in checkargs
>>   return cmdfunc()
>>  File "C:\~env\Python26\lib\site-packages\mercurial\dispatch.py",
>> line 453, in <lambda>
>>   d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
>>  File "C:\~env\Python26\lib\site-packages\mercurial\util.py", line
>> 386, in check
>>   return func(*args, **kwargs)
>>  File "C:\~env\Python26\lib\site-packages\mercurial\commands.py",
>> line 2356, in push
>>   r = repo.push(other, opts.get('force'), revs=revs)
>>  File "C:\~env\Python26\lib\site-packages\hgext\mq.py", line 2501, in push
>>   return super(mqrepo, self).push(remote, force, revs)
>>  File "build\bdist.win32\egg\hggit\hgrepo.py", line 19, in push
>>   git.push(remote.path, revs, force)
>>  File "build\bdist.win32\egg\hggit\git_handler.py", line 147, in push
>>   changed_refs = self.upload_pack(remote, revs, force)
>>  File "build\bdist.win32\egg\hggit\git_handler.py", line 548, in
>> upload_pack
>>   raise hgutil.Abort("the remote end hung up unexpectedly")
>> Abort: the remote end hung up unexpectedly
>> abort: the remote end hung up unexpectedly
>
> That just looks like the remote server doesn't like something dulwich sent.

How can I trace it then? Some hidden --git-trace key perhaps?

>>> I have no resources for testing things on Windows, and until now all the
>>> windows users have just complained and not offered fixes - I'll
>>> appreciate
>>> any patches you can provide.
>>
>> It would be much easier to provide patches for last released version
>> rather than "trunk". It takes significantly less time to use "hg init"
>> etc. than trying to guess working HgGit/Dulwich combination to be able
>> to download latest version from git repositories (at least for
>> Dulwich), compile them and install.
>
> That's fine. I've never seen *any* patches at all, against recent or release
> versions. That said, dulwich and hg-git have both been moving targets
> lately, and thus far all the "windows failures" I've seen are
> indistinguishable from fixed bugs when looking at a traceback (like the
> above).

Usually you install stable version to use it. Then you see a bug, you
download a latest trunk version of HgGit. If bug is still here (and
you presume that is was not overlapped by other bug caused by
dependency on newer Dulwich) then you try to see if it is a Dulwich
problem. You need to ask in this list, because you do not know the
code. You find this mailing list, you describe the problem. You are
asked to update the code, you start working on the patch. You are
distracted and a few weeks later you need to start from scratch,
because your working directory is messed with patches and you do not
remember all exact conditions that caused the but. It is the state I
am now on. The release to sync is highly desired.

>> Dulwich doesn't compile without
>> --pure option on Windows and it may happen that I am alone among
>> Windows users who knows how to compile it.
>
> Then I appreciate your expertise and look forward to your help.

Usually there are binary distributives for windows users, but you
can't provide these for every commit, and if you're working on the
patch yourself, such update will likely to kill your modifications.

So the only cure is "Install from source" instructions, that Windows
users can be pointed to to try latest trunk version and/or
troubleshooting tutorial.

>> This can easily overwhelm
>> and demotivate contributors. My attempt to work with Dulwich was not
>> the first, BTW. In previous attempts I've run out of time without any
>> outcomes or even questions.
>
> I've had questions from a fair number of other users on windows. My answer
> is usually that I'm clueless about their problems once they relate it to
> being on Windows - that's the truth. I'd learn, but my time is already
> stretched thin enough as it is. I'm *unbelievably* glad you're willing to
> take a closer look and have some notion of what to look for.

Let's make this constructive. Does "hg inc" command work with HgGit? I
need it quite often and it is the easiest part I can troubleshoot for
the moment, because it doesn't change the state of local repository,
so I don't have to maintain scripts that pasture and breed various
states in repo copies.

>> patchbomb requires SMTP server and I do not have any except GMail. And
>> the last thing I want is to store my GMail credentials in cleartext
>> format. patchbomb could be more useful with Gmail OAuth.
>
> You don't have to put the credentials hardcoded in a file IIRC - I believe
> it'll prompt for the password. patchbombs are *orders of magnitude* easier
> to review than patches attached to an issue tracker, and are (for me)
> significantly less likely to be forgotten.

For me issue trackers are easier to track that mails. Do you need a
tool to query trackers for patches? Could you spare some minutes to
describe your process of reviewing patchbombs and committing them in
steps, so that I can imagine the *order of magnitude*. =)

> Have you filed an enhancement bug about OAuth support in Merucial's issue
> tracker? That sounds like a decent nice-to-have.
> http://mercurial.selenic.com/bts/

I hope these two are enough for now for patchbombers.

http://mercurial.selenic.com/bts/issue2141
http://mercurial.selenic.com/bts/issue2142

-- 
anatoly t.