[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Sync Issue

From: Stephen Leake
Subject: Re: [Monotone-devel] Sync Issue
Date: Thu, 06 Mar 2008 07:48:40 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.1 (windows-nt)

"Marcin W. DÄ…browski" <address@hidden> writes:

> Hi.
> I've noticed the following change via CIA:
> I'm using 'file:' on Win32, and it works just right for me. The
> fact that it is to be disabled in next release worried me a bit.

It will stop working when you get to a big enough database or
workspace. The problem is the failures are hard to reproduce.

>> If that is what you are using, switch to Cygwin monotone,
>> if only for those sync operations. That's what I use, and
>> it works reliably.
> Why one should use two binaries of one app which should work the
> same on every platform?

I agree it _should_ work correctly on native Win32, but it doesn't.

On the other hand, it is often the case that testing on one Windows
box has no predictive power for another Windows box; "Windows" is not
a solid operating system. So maybe it does really work on your boxes.
Other users have also reported problems, including others on my team
at work.

>> We should document the broken Win32 operations in the manual,
>> and possibly disable them in the code.
> Documenting wrong behavious and describing possible workarounds
> is good. Fixing the bug is even better. But disabling the feature
> in the code is just like breaking the functionality - and this is
> bad thing...

I have people on my team who don't read even our own setup manuals,
and so try to use file: on native Win32, and then ask me for help when
it hangs. (Sigh). So it's simpler if the tool says right up front
"this won't work".

If there is strong objection to disabling this outright, I can
probably disable it in a local Lua hook.

> For example, recently I'm doing some cleanups in our repositories,
> and have to go thru the following steps:
>     mtn db init -d project.db
>     mtn setup . -b project/edge -d project.db
>     mtn pull file:project-branch1.db project-devel-branch1
>     mtn pull file:adam-project.db address@hidden/project
>     mtn pull file:docs.db docs-xml-project
>     mtn add -R dev dm doc
>     mtn ci -m "Workspace merge - CM step 1."
>     mtn merge_into_dir project-devel-branch1 project/edge branch-1
>     mtn merge_into_dir address@hidden/project project/edge src
>     mtn merge_into_dir docs-xml-project project/edge docsrc
>     mtn up
> Is there any other way to sync two separate databases on Win32
> without the need for '-serve'?

Yes; do exactly those steps, but use the Cygwin mtn. Is that really a

One problem with Cygwin is the /cygdrive/c/ syntax; it doesn't match
other tools that use the Win32 syntax. The best fix for that is to
install Cygwin at c:/ instead of the default c:/cygwin. Then, at least
for the c: drive, Cygwin paths will match Win32 paths.

The installer will complain, but it's really just saying "this will
install stuff in c:/bin; we're worried you might have other stuff
there". So just do it :).

> What's the problem with 'file:' and how can I help to fix it, and
> bring it back to Win32?

See the branches n.v.m.win32_pipes, n.v.m.win32_pipes_2 for some
attempts to fix it.

The core problem is the attempt to emulate 'select' on Win32; it's not
quite right. There are tests in n.v.m.win32_pipes that show the low level

I think the best approach is to switch from netxx to asio (see the
other thread on asio). Or to some other supported networking library
that fully supports async files and pipes on Win32. Which is one
description of Cygwin :).

-- Stephe

reply via email to

[Prev in Thread] Current Thread [Next in Thread]