bfiles: Autoput to an HTTP(S) repo, and strange behaviour of update -C
Greg Ward
greg-hg at gerg.ca
Sun Oct 24 01:34:42 UTC 2010
On Mon, Sep 27, 2010 at 12:33 PM, Oleg Frantsuzov <franoleg at gmail.com> wrote:
> I'm trying to set up the bfiles extension in our environment. We use
> Windows and TortoiseHg 1.1.2 packaged with Mercuriral 1.6.2. The
> bfiles extension is current trunk, changeset 5f3a0e4c06f4 (Sep 26,
> 2010). Our changeset flow model is centralized, with a master
> repository accessible via HTTPS. Since we wanted everything to be as
> straightforward as possible, I set up all of the autostatus /
> autoupdate / autorefresh / autoput options.
Sorry for the delay. I went on vacation just about exactly when you
sent that message. Got back a week ago, but I'm only now starting on
the mountain of email.
> However, when I first
> tried to trigger bfput by pushing to our central server repository, I
> encountered this error:
>
> ========
> D:\HgTest\test_bfiles>hg push
> pushing to https://fog:***@server/hg/test_bfiles/
> ** unknown exception encountered, details follow
> ** report bug details to http://mercurial.selenic.com/bts/
> ** or mercurial at selenic.com
> ** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
> ** Mercurial Distributed SCM (version 1.6.2)
> ** Extensions loaded: fixfrozenexts, bfiles
> Traceback (most recent call last):
> File "hg", line 36, in <module>
> File "mercurial\dispatch.pyo", line 16, in run
> File "mercurial\dispatch.pyo", line 34, in dispatch
> File "mercurial\dispatch.pyo", line 54, in _runcatch
> File "mercurial\dispatch.pyo", line 490, in _dispatch
> File "mercurial\dispatch.pyo", line 351, in runcommand
> File "mercurial\dispatch.pyo", line 541, in _runcommand
> File "mercurial\dispatch.pyo", line 495, in checkargs
> File "mercurial\dispatch.pyo", line 488, in <lambda>
> File "mercurial\util.pyo", line 420, in check
> File "mercurial\commands.pyo", line 2853, in push
> File "c:\Progra~1\TortoiseHg\extensions\hg-bfiles\bfiles\bfsetup.py",
> line 182, in push
> if fnmatch.fnmatch(remote.root, autoputrepo):
> AttributeError: 'httpsrepository' object has no attribute 'root'
> ========
>
> It turns out, httprepository class and its subclass httpsrepository
> have no root attribute. In fact, the attributes httprepository and
> localrepository have in common are path and url, but they return
> different values:
Oooops. Clearly the test coverage for autoput is not sufficient.
Thanks for the analysis! I'll see if I can beef up the tests.
> # HG changeset patch
> # User "Oleg Frantsuzov" <franoleg at gmail.com>
> # Date 1285604476 -14400
> # Node ID 1ee9963b78bf3a822afdd4be5bee0803ddffc574
> # Parent 5f3a0e4c06f47c4f7e4d8b3e520e97a0f47da066
> Support http repositories as autoput targets.
>
> diff --git a/bfiles/bfsetup.py b/bfiles/bfsetup.py
> --- a/bfiles/bfsetup.py
> +++ b/bfiles/bfsetup.py
> @@ -179,7 +179,11 @@
> def push(self, remote, *args, **kwargs):
> for autoputrepo in autoputrepos:
> # XXX does this work when remote is an http or ssh repo?
> - if fnmatch.fnmatch(remote.root, autoputrepo):
> + if hasattr(remote, "root"):
> + root = remote.root
> + else:
> + root = remote.path
> + if fnmatch.fnmatch(root, autoputrepo):
I suspect that the solution will end up looking much like this. ;-(
The *right* answer is to refactor Mercurial so the repository classes
are a little more consistent, but that'll have to wait until after 1.7
is released.
> Moreover, I've came across a really confusing bug which I'm trying to
> investigate right now. Consider the following scenario: a repo with
> configured store / autostatus / autoupdate / autorefresh / autoput
> options has these changesets (hello.exe is a binary file put under
> bfiles via bfadd command):
>
> ========
> D:\HgTest\test_bfiles>hg st --change 3
> M hello.cs
> M hello.exe
>
> D:\HgTest\test_bfiles>hg st --change 2
> A hello.exe
>
> D:\HgTest\test_bfiles>hg st --change 1
> A build.bat
> A hello.cs
>
> D:\HgTest\test_bfiles>hg st --change 0
> A README.txt
> ========
>
> In this repo, I try to update to the rev 3 from the rev 2 with -C
> (--clean) option set. However, even though the autoupdate option in
> hgrc is out, bfiles autoupdate wrapper is not started by some reason.
> When I try to update without -C, autoupdate works OK:
>
> ========
> D:\HgTest\test_bfiles>hg up -r 3 -C
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> D:\HgTest\test_bfiles>hg up -r 3
> 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 1 big files updated, 0 removed
> ========
Hmmm. "hg update" and "hg update -C" actually follow different code
paths, and offhand it looks as though bfiles' auto-update feature
simply forgot to handle the "update -C" path. Again: ooops! More
testing in order. I've opened
https://bitbucket.org/gward/hg-bfiles/issue/20/ so I don't forget.
> As I've mentioned earlier, I'm trying to investigate the reasons
> behind this, however I'm curious if there are any ideas about what can
> be the cause of this or whether it's a feature, not a bug. I perceive
> this as an obstacle because, for some reason, TortoiseHg fires update
> with the -C options, so it's pretty much impossible to use TortoiseHg
> together with the bfiles extension.
Really?!? No way! TortoiseHg is way too smart to do that by default.
In fact I'm pretty sure you have to set a toggle to explicitly ask it
to run with -C. Are you *sure* that's what's happening?
Thanks for the bug reports!
Greg
More information about the Mercurial
mailing list