I'm just getting started using monotone 0.33 on Windows XP, from the
binary install.
When I ran 'mtn genkey', it stored the key in
C:/Documents and Settings/stephe/Application Data/monotone/keys/
which is reasonable on Windows. But I'd rather it be stored in
c:/Stephe/.monotone, because I
I'm considering switching to monotone; I currently use CVS.
One reason for switching is the requirement to do CM on a system that
has no network access, for security reasons (this is for NASA, we
worry about people taking over satellites).
The basic scenario is we have several developers, and
I've successfully installed the MSYS tools, and I'd just like to say
thank you to the maintainers of the Monotone Wiki, especially the
BuildOnWindows page.
It was a pleasure following such clear, detailed instructions. I have
attempted to install MinGW before for other tools, but always failed;
Nathaniel Smith [EMAIL PROTECTED] writes:
On Wed, Apr 11, 2007 at 08:16:38PM +0200, Markus Schiltknecht wrote:
--- key_store.cc70b97a9e2a06654ec641a1709c2a875cdfa603d5
+++ key_store.ccfda46d5fa8a5b2a52421c1f83413a208e2c6401f
@@ -1,4 +1,5 @@
#include sstream
+#include
Timothy Brownawell [EMAIL PROTECTED] writes:
On Sat, 2007-04-14 at 09:46 -0400, Stephen Leake wrote:
To sync the central database with a non-networked target system:
1) Install the USB drive in a developer machine, and sync the
developer's local database with it.
2) Install the USB
Richard Levitte [EMAIL PROTECTED] writes:
so, I'm considering making a new release (0.35) some time next week or
so, preferably before the end of April [0]. This is a good time to
fill in a little bit of news in the NEWS file if you have any.
I'm new to monotone, so I'm not familiar with the
Thomas Keller [EMAIL PROTECTED] writes:
Daniel Carosone schrieb:
On Sun, Apr 22, 2007 at 07:03:36PM +0200, Christian Ohler wrote:
The reason why xmtn doesn't have a proper implementation of
dvc-status yet is that xmtn doesn't have a parser for mtn automate
inventory; I was hoping to be able
Daniel Carosone [EMAIL PROTECTED] writes:
On Tue, Apr 24, 2007 at 02:51:35AM -0400, Stephen Leake wrote:
I can help with the tests and documentation.
Excellent.
What should I do first?
I've got the monotone.basic_io.inventory branch compiled (on Win32
with MinGW).
I've looked thru
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
I don't see many commands that take a fileid; the commands most
interesting from an Emacs interface point of view just need the file
path. So perhaps fileid output should be requested via an option, to
save parsing time
Stephen Leake [EMAIL PROTECTED] writes:
Daniel Carosone [EMAIL PROTECTED] writes:
So I'd like to add an option to not output any info for files that are
currently up-to-date. That would save significant time both in running
'mtn automate inventory' and in parsing the output in Emacs
Stephen Leake [EMAIL PROTECTED] writes:
I can help with the tests and documentation.
I've taken a first stab at updating
tests/automate_inventory/__driver__.lua, and adding some comments in
automate.cc.
As an aside, I found the lua test framework quite nice, once I figured
out how to run
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
Stephen Leake [EMAIL PROTECTED] writes:
I can help with the tests and documentation.
I've taken a first stab at updating
tests/automate_inventory/__driver__.lua, and adding some comments in
automate.cc.
Wow... you've been
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
For the tests, I think you should implement the actual matching after
you've parsed the basic_io properly. For this there exists a function
named parse_basic_io which takes the basic_io string as input and
returns a lua table
Here is a possible fix for umask in key_store.cc on MinGW:
--- key_store.cc
+++ key_store.cc
@@ -115,7 +115,7 @@ key_store::ensure_in_database(rsa_keypai
I(app.db.public_key_exists(ident));
return;
}
-
+
if
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
Is there some documentation on these requirements for basic_io
parsers?
snip...
Hrm... I don't see that either.
Ok. I'll write this up on the BasicIoFormalization wiki page, and
start another discussion thread.
What do you
Zack Weinberg [EMAIL PROTECTED] writes:
On 4/28/07, Stephen Leake [EMAIL PROTECTED] wrote:
Here is a possible fix for umask in key_store.cc on MinGW:
I don't mean to rain on your parade,
No problem; I was just trying to get things to compile, and getting
back into writing C++.
but I really
Christian Ohler [EMAIL PROTECTED] writes:
On my machine, mtn automate inventory (from
65dcf7bd70c798d6a8d4216628ad664223e52295) needs about 1.13s wall time
to generate its output for its own source tree (with hot caches,
without inodeprints, output redirected). (Stephen, I suspect you're
Thomas Keller [EMAIL PROTECTED] writes:
Hi all!
I just pushed 0472d09c092424674bae4acfced5c51dc51de408 which drops the
file ids and rather displays old and new path of an item together with
a status string. Example output:
snip
This looks excellent.
I ran Christian's timing test on this
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
$ mtn rename foo tmp
$ mtn rename bar foo
$ mtn rename tmp bar
So if the user had done 'automate inventory' between each of these
steps, it would have been clearer.
Let's see; 'path' gives the name in the current workspace
I've checked in a change on the nvm.basic_io.inventory branch to
tests/automate_inventory/__driver__.lua; it now passes with the
current 'automate inventory' output.
I added some FIXME comments where I think things are confusing or
wrong.
I think the format of the tests is now quite readable,
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
So, its actually this way: If a file is dropped (status dropped),
'path' is the path in the old roster. If a file is added (status
added), 'path' is the path in the new roster. If a file is renamed,
'path' is either an old
Derek Scherger [EMAIL PROTECTED] writes:
One thought that along these lines is that perhaps we should change the
entire focus from paths to nodes:
node 1234
old_name foo
new_name bar
old_content [1234...]
new_content [5678...]
status renamed patched
node 5678
old_name
new_name
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
Right. The only reason I'm talking about changing the format at all is
because you have posted some corner cases that are currently broken,
and I believe this change would fix those.
One of my last commits fixed the DRx
Stephen Leake [EMAIL PROTECTED] writes:
I can't find a manual for the Gnu linker, after half an hour of
searching around on the web!
To be more precise, an ask.com search found
http://www.gnu.org/software/binutils/manual/ld-2.9.1/, but that's out
of date ('ld --version' reports 2.15). ld used
Matthew Gregan [EMAIL PROTECTED] writes:
At 2007-05-20T10:42:00-0400, Stephen Leake wrote:
When I run a mtn on Windows, it fails with no message if the required dlls
are not in PATH.
The DLLs do not need to be in the PATH. Windows will look for them in the
same directory as the monotone
Benoît Dejean [EMAIL PROTECTED] writes:
Oh, and yes, it should and tries to, but on a network filesystem, cache
issues are big. I work in a big company, with a really huge intranet
(worldwide). The filer i use is 1000km away, so the RTT is ~15ms. There
are some NFS/CIFS/etc accelerators, but
Justin Patrin [EMAIL PROTECTED] writes:
IIRC there are 2 major reasons we're trying to remove the non-geader
stuff in boost.
1) It's a huge stumbling block for people installing monotone. Boost
tends to be a huge pain to build for many people on many platforms.
This seems to have gotten
Zack Weinberg [EMAIL PROTECTED] writes:
branches? Do any work? Which are up-to-date?
...
No work has been done since the summit. The present state of play is,
you can do 'mtn merge_into_workspace revision' which will merge
revision with the current workspace's parent (I forget what
Richard Levitte [EMAIL PROTECTED] writes:
Does that mean that the Windows crowd is uninterested in monotone?
No!
I'm planning on using monotone on Windows/MinGW as a replacement for
CVS, for real work.
I'd also like to port monotone to Lynx. I got it to compile, but the
tests totally fail. It
Zack Weinberg [EMAIL PROTECTED] writes:
If you have a conflicted file in a roster, it is marked as conflicted
in the status output. You get four copies of the file in your
workspace: ancestor, left, right, and merged-with-conflict-markers
(respectively: myfile.ancestor.rev, myfile.revL,
I'd like to get nvm.basic_io.inventory merged into the main line.
Emacs DVC is working well with the current implementation. It would be
good to get this into the released version.
Last week I merged nvm into nvm.basic_io.inventory. All of the
automate inventory tests are passing; some others are
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
I'd like to get nvm.basic_io.inventory merged into the main line.
Emacs DVC is working well with the current implementation. It would be
good to get this into the released version.
Have you been able to sort out all
Zack Weinberg [EMAIL PROTECTED] writes:
There was some sort of merge trainwreck affecting de.po today. One
side of the merge had ediff merge markers in its content, which made
it really fun to try to figure out what the proper merge was. On top
of that, the file had somehow gotten
Derek Scherger [EMAIL PROTECTED] writes:
The format for outputing the root directory is still problematic. I
think the simplest solution is to simply not output it; in Emacs DVC,
we just drop that directory from any display.
Let's use a . and start a trend! ;)
I've checked in a change that
Stephen Leake [EMAIL PROTECTED] writes:
Derek Scherger [EMAIL PROTECTED] writes:
The format for outputing the root directory is still problematic. I
think the simplest solution is to simply not output it; in Emacs DVC,
we just drop that directory from any display.
Let's use a . and start
Matthew Gregan [EMAIL PROTECTED] writes:
At 2007-07-22T14:39:41-0700, Justin Patrin wrote:
and on Windows XP (MingW):
Interesting tests:
177 empty_environment FAIL (line -1)
I don't have time to look at the others right now, but I'm pretty sure this
test is
Matthew Gregan [EMAIL PROTECTED] writes:
Both MinGW and MSVC need libintl-8 for i18n.
Hmm. Then either the binary release for Windows does a static link
with libintl-8, or it is broken. Or you are mistaken.
Or I'm compiling with some switch that disables i18n? Hmm. config.log
says I just ran
Richard Levitte [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] on Wed, 25 Jul 2007 07:20:37 -0400, Stephen
Leake [EMAIL PROTECTED] said:
stephen_leake Does the MSVC build need libintl-8.dll (I don't have
stephen_leake MSVC installed)? If not, then this patch can be
stephen_leake
Thomas Keller [EMAIL PROTECTED] writes:
Thomas Keller schrieb:
... I think a good solution
for the above bug would be the your idea of having a --hide-ignored
and/or --hide-unknown-and-ignored flag - whats the status of this anyways?
Anyone up for that?
I plan on doing it eventually, but
I've committed fixes for the latest failing tests in
automate_inventory and automate_inventory_path.
Then I experimented with the special case for ; it passes all
current tests if it only special cases the path, not the rest of the
stanza. So I committed that. I added a test for the case of a
Thomas Keller [EMAIL PROTECTED] writes:
Stephen Leake schrieb:
Looking at other tests, it seems tests/test_utils_inventory.lua should
be tests/common/test_utils_inventory.lua; should I move it?
Yeah, seems more plausible - I meant to do it as well but then I thought
maybe you'll recognise
Richard Levitte [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] on Thu, 02 Aug 2007 12:00:47 +0200, Markus
Schiltknecht [EMAIL PROTECTED] said:
markus Considering that we really care only since we have the
markus buildbots in place again, it seems a little silly to me to
markus hold
I'm getting an error from the top level Makefile. I'm running on Win32
MinGW.
make check
/usr/bin/make check-recursive
...
make[3]: `tester.exe' is up to date.
make[3]: Leaving directory `/c/Gnu/monotone-build_mingw'
/usr/bin/make check-local
make[3]: Entering directory
I tried to fix the compilation errors in tester on WIN32; see
824a6c7947919ec2a96e41c3e8862712651e44be
But it's still broken; running `run_lua_tests' gives:
1 (imp)_deleting_directoriesFAIL (unhandled exception in
child process)
and the same error for all 454 tests.
Same
Zack Weinberg [EMAIL PROTECTED] writes:
If you do not have these things, you need to run autoreconf -i in the
source tree, wipe out your build tree and re-configure it.
That fixed part of it; now I have the 'check-local' target. I had done
'autoconf', but not 'autoreconf -i'. I'll write that
Stephen Leake [EMAIL PROTECTED] writes:
I tried to fix the compilation errors in tester on WIN32; see
824a6c7947919ec2a96e41c3e8862712651e44be
But it's still broken; running `run_lua_tests' gives:
1 (imp)_deleting_directoriesFAIL (unhandled exception
in child process
Zack Weinberg [EMAIL PROTECTED] writes:
On 8/29/07, Stephen Leake [EMAIL PROTECTED] wrote:
[...]
I'm using the MinGW distribution, as described on the monotone Wiki,
updated just a month ago.
This doesn't answer the question, I'm afraid. The problem seems to be
resolved, but what I wanted
Jack Lloyd [EMAIL PROTECTED] writes:
On Wed, Aug 29, 2007 at 06:21:55AM -0400, Stephen Leake wrote:
I'm not very familiar with C++ debugging. I'm using gdb from the
AdaCore distribution (there isn't one in the MinGW distribution); it
understands C++, but break exception isn't a recognized
When monotone needs help merging, it uses the following to launch
emacs:
local elisp =
(ediff-merge-files-with-ancestor \%s\ \%s\ \%s\ nil \%s\)
local ret = execute(emacs, --eval,
string.format(elisp, tbl.lfile, tbl.rfile, tbl.afile, tbl.outfile))
This fails on Win32, because the
Zack Weinberg [EMAIL PROTECTED] writes:
On 8/30/07, Stephen Leake [EMAIL PROTECTED] wrote:
Should I commit that change in tester.cc posix_umask, or is there a
better solution? I think 'umask' isn't meaningful on Win32.
Yes, please commit the change to posix_umask. It is indeed
Stephen Leake [EMAIL PROTECTED] writes:
... For example, a typical file is:
C:\DOCUME~1\stephe\LOCALS~1\Temp/mtn.left.QEBJ8B
Emacs lisp turns this into:
C:DOCUME~1 tepheLOCALS~1Temp/mtn.left.QEBJ8B
Escaping the backslashes is straightforward; they just need a
preceding backslash:
C
On 11 Jul 2007, Zack Weinberg wrote:
The present state of play is, you can do 'mtn merge_into_workspace
revision' which will merge revision with the current workspace's
parent (I forget what happens if there are local changes; I think it
errors out) and dump the result into the workspace.
spawn_redirected_hook_helper test is failing on Win32 MinGW.
The root problem seems to be a race condition in waiting for the test
child process; the test works if I run under the debugger and put
breakpoints in the right places. I suspect the problem is related to
having two child processes; the
These tests are failing:
17 _--author,_--date FAIL (exit 1)
18 _--confdir_option_and_get_confdir_lua_function_work FAIL (exit 1)
19 _--db_with_parent_dir FAIL (exit 1)
20 _--rcfile=- FAIL (exit 1)
21
These tests are now failing on Win32 MinGW:
113 checkout_validates_target_directory FAIL (line 24)
118 clone_validates_target_directory FAIL (line 26)
They both rely on chmod and permission enforcing. Reproducing the
basic operations in a MinGW Msys shell shows that it
Zack Weinberg [EMAIL PROTECTED] writes:
On 9/1/07, Stephen Leake [EMAIL PROTECTED] wrote:
The problem is this line in tester.cc parse_command_line:
else if (argv[i][1] == '-')
{
P(F(unrecognized option '%s') % argv[i]);
it should be:
else if (argv[i][0
Richard Levitte [EMAIL PROTECTED] writes:
So I've a proposal to make this easier, and it's to have a hook
registry in monotone, and changing the way hooks are implemented to be
anonymous functions that are used as arguments to a registration
function, 'add_hook' perhaps?
That would at least
Nathaniel Smith [EMAIL PROTECTED] writes:
I get the impression that the inventory fixes, for instance, are just
stalled because everyone is nervous there are things they haven't
thought of and that could be arbitrarily bad, I mean who *knows* what
you haven't thought of, you certainly
Matthew Sackman [EMAIL PROTECTED] writes:
On Wed, Sep 05, 2007 at 03:19:02PM +0200, Richard Levitte wrote:
In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 13:54:23 +0100, Matthew
Sackman [EMAIL PROTECTED] said:
matthew Each hook can return one of three values: everything ok;
matthew
William Uther [EMAIL PROTECTED] writes:
I'm happy with that. But I'd like the scripts to be cross platform.
Gnu bash scripts should be sufficiently cross-platform; they run on
all the platforms I'm aware of.
--
-- Stephe
___
Monotone-devel
Richard Levitte [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 12:22:43 +0200, Julio M.
Merino Vidal [EMAIL PROTECTED] said:
jmmv84 Using plain text messages will make one think twice before
jmmv84 doing that, because he'll have to explain *why* he is
jmmv84
Richard Levitte [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] on Wed, 05 Sep 2007 17:31:59 -0400, Stephen
Leake [EMAIL PROTECTED] said:
stephen_leake I was waiting for the 0.36 release to be done to raise
stephen_leake this issue again, and then I was waiting for time
Derek Scherger [EMAIL PROTECTED] writes:
Stephen Leake wrote:
I haven't heard any objections to this; a couple people said they
would review the docs and such.
So if I have not heard any objections by this weekend (Sept 15), I'll
merge nvm.basic_io.inventory to nvm then.
Ok?
I haven't
Richard Levitte [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 07:12:54 -0400, Stephen
Leake [EMAIL PROTECTED] said:
stephen_leake On the other hand, that is the way we typically work. I
stephen_leake often notice little things while I'm working on one
Derek Scherger [EMAIL PROTECTED] writes:
Thomas Keller wrote:
Looks good. I did some small tweaks on the command line and version
display, but the rest seems to be fine. Just one thing hit my eyes:
Full support for versioned directories is not yet complete and the
inventory will only list
Derek Scherger [EMAIL PROTECTED] writes:
I vaguely recall some mention of a restricted inventory case where only
one side of a rename was listed in the inventory. Is there a test for
this?
Yes; see tests/automate_inventory_restricted/__driver__.lua, search
for the comment:
-- Rename a file
Derek Scherger [EMAIL PROTECTED] writes:
At a glance the docs look reasonable. I'm still not sure I prefer the
old_path and new_path stuff over the node id's though.
It's a compromise. Can you live with it?
Also, I see a FIXME in the docs for the invalid status
Yes, it needs a test. But
Derek Scherger [EMAIL PROTECTED] writes:
Stephen Leake wrote:
I have wondered about the proper format/content for changes in nvm.
I'd appreciate some written guidance in HACKING.
If nothing else the current ChangeLog file does give a bit of info about
this along with saying
Derek Scherger [EMAIL PROTECTED] writes:
Stephen Leake wrote:
Derek Scherger [EMAIL PROTECTED] writes:
BTW, has anyone looked at this branch? I think it's an improvement
and fixes a couple of invariant failures. Please see my earlier
emails for details.
I just looked thru the log
INSTALL says autoconf should be run as autorecconf -i, but the top level
makefile just runs autoconf, which doesn't do enough after some
updates. So then the build fails mysteriously later, and eventually I
remember to do 'autoreconf -i' and start over.
This appears to be a bug in automake; it
I've merged net.venge.monotone.basic_io.inventory into
net.venge.monotone; see 07ae9cb7bea973d20cea3ff3db935744e66e9789.
I bumped interface_version in cmd_automate.cc to 6.0; this is a
backward-incompatible change.
--
-- Stephe
___
Monotone-devel
revert_unchanged_file_preserves_mtime is failing intermittently on
Win32.
That is, most of the time it fails, but sometimes it passes.
This test is looking at file modification times; they should either
increase or not change.
The failure happens when they decrease.
From the test log, it looks
Stefan Monnier [EMAIL PROTECTED] writes:
Bak when I used monotone for the first time, I was surprised to see that
all the merge options provided were pretty much modal. So I came up with
the code attached below (not on my own, it's largely copied from random
bits on the Web, it's probably
Ralf S. Engelschall [EMAIL PROTECTED] writes:
I've now improved my diffutils merger implementation in std_hook.lua.
One now can use MTN_MERGE_DIFFUTILS=partial to get the results
of contrib/diff3_keep_conflicts_merger.lua. When combined with
merge_into_workspace as in...
$
Ralf S. Engelschall [EMAIL PROTECTED] writes:
On Sun, Sep 23, 2007, Stephen Leake wrote:
However, --show-overlap removes the 'ancestor' information from the
merged output; sometimes, that info is useful. So I think I prefer
running diff3 without --show-overlap. I'll have to try it some more
Nathaniel Smith [EMAIL PROTECTED] writes:
I just noticed that we seem to have only one win32 buildslave at the
moment, and it's building with VS2005 -- which is cool, but VS support
is broken and we have never used it for actual releases in any case.
So at the moment we have.. no automated
Zack Weinberg [EMAIL PROTECTED] writes:
On 9/23/07, Derek Scherger [EMAIL PROTECTED] wrote:
I've been playing around a bit with the rather cryptic messages that
monotone generates on so called non-content conflicts and hopefully have
improved things a bit.
Cool! Your revisions are
Nathaniel Smith [EMAIL PROTECTED] writes:
On Mon, Sep 24, 2007 at 06:32:41AM -0400, Stephen Leake wrote:
Nathaniel Smith [EMAIL PROTECTED] writes:
I just noticed that we seem to have only one win32 buildslave at the
moment, and it's building with VS2005 -- which is cool, but VS support
Nathaniel Smith [EMAIL PROTECTED] writes:
I just stumbled across this code in CMD_AUTOMATE(inventory):
if (i-first.as_internal() == )
{
// This is the workspace root directory; print a nicer name.
st.push_str_pair(syms::path, .);
}
else
Zack Weinberg [EMAIL PROTECTED] writes:
Tangentially, the chain of foo error: strings that get tacked on the
beginning of the actual error message is getting kind of absurd here,
doncha think? --
mtn: Fataler Fehler: std::runtime_error: Netzwerk-Fehler: recv failure:
(with precisely half
Nathaniel Smith [EMAIL PROTECTED] writes:
On Tue, Sep 25, 2007 at 05:01:39AM -0400, Stephen Leake wrote:
If no one else speaks up, I'll commit those changes.
Do it! :-)
Done.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel
Richard Levitte [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] on Wed, 3 Oct 2007 12:45:25 +0100, Matthew
Sackman [EMAIL PROTECTED] said:
matthew Hmmm. Are all those contributors active? It seems odd to be
matthew happy to ship scripts which are highly unlikely to work with
matthew
Lapo Luchini [EMAIL PROTECTED] writes:
Zack Weinberg wrote:
Would
requiring a working Perl installation (it doesn't look like it needs
anything beyond a basic 5.x perl) be too much of a hindrance?
As far as Cygwin and FreeBSD go, I never want perl in my system and
*always* end up needing
I've just updated to 45c06e2f6d0180bf5d80716d069a76a388f65291, and
`configure' is failing; I'm using Win32 MinGW.
I did 'autoreconf -i'.
configure is failing on line 11398 (PKG_CHECK_MODULES below):
# Check whether --with-system-pcre or --without-system-pcre was given.
if test
Richard Levitte [EMAIL PROTECTED] writes:
Until then, it might be a good idea to have a look at the buildbot
page. I'm noticing that the BSD, Solaris and gentoo slaves fail the
tests. I haven't looked more closely at them yet (well, except for
one of the failing tests on the amd64-freebsd6
I'm getting link failures in mingw due to pcre.
I configured with '--without-system-pcre', which results in a static
link.
The fix is to add
#include pcre_config.h
to pcrewrap.cc, to pick up the #define of PCRE_STATIC.
It would be nice if pcre.h did '#include pcre_config.h', but all the
Stephen Leake [EMAIL PROTECTED] writes:
I've just updated to 45c06e2f6d0180bf5d80716d069a76a388f65291, and
`configure' is failing; I'm using Win32 MinGW.
I did 'autoreconf -i'.
configure is failing on line 11398 (PKG_CHECK_MODULES below):
snip
It appears that PKG_PROG_PKG_CONFIG
Stephen Leake [EMAIL PROTECTED] writes:
Richard Levitte [EMAIL PROTECTED] writes:
Until then, it might be a good idea to have a look at the buildbot
page. I'm noticing that the BSD, Solaris and gentoo slaves fail the
tests. I haven't looked more closely at them yet (well, except for
one
Zack Weinberg [EMAIL PROTECTED] writes:
On 10/21/07, Stephen Leake [EMAIL PROTECTED] wrote:
In cygwin, I found these macros in /usr/share/aclocal/pkg.m4. That
file is part of the pkg-config package.
So if I don't have pkg-config, then I don't have those macros, so they
can't be part
We have two conflicting needs in pcrewrap.cc.
mtn log pcrewrap.cc shows:
| | Revision: 9bcc5db83aec83c2328bdb0ffa6ddd73d2c02605
| | Ancestor: ef2de17663a2463d3ac24cb789bc2a1895017409
| | Author: [EMAIL PROTECTED]
| | Date: 2007-10-26T12:24:22
| | Branch: net.venge.monotone
| |
| |
There is still no 0.37 Win32 binary on http://monotone.ca/.
Should I build one? I assume I just do make distrib?
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Stephen Leake [EMAIL PROTECTED] writes:
We have two conflicting needs in pcrewrap.cc.
snip
We need a way for pcrewrap.cc to set PCRE_STATIC, based on the choice
made by configure.
Monotone has its own 'config.h'; we could add PCRE_STATIC there. A
one-line change in m4/pcre.m4 does
Zack Weinberg [EMAIL PROTECTED] writes:
If you are getting this as a direct mail instead of via the list, then
you made more than a couple lines' worth of changes to the monotone
manual at one time or another, but I do not know if you have agreed to
relicensing. [3] I ask you:
PLEASE
Richard Levitte [EMAIL PROTECTED] writes:
As it is now, there are quite a lot of linking problems with pcrewrap,
and I'm wondering if it's simply that _WIN32 needs to be defined in
visualc/pcre.vcproj... But I feel unsure about it, as I thought that
was a preprocessor symbol the compiler
Richard Levitte [EMAIL PROTECTED] writes:
stephen_leake It should have been fixed by
stephen_leake 62ac15e65e9e97d3c5032fed1ea4cbddbc9fc11d, committed
stephen_leake 2007-11-07T10:43:41
Aha, thanks!
stephen_leake It requires the buildbot to run 'autoreconf -i' after
stephen_leake updating;
William Uther [EMAIL PROTECTED] writes:
If you're going to have the key show up as [EMAIL PROTECTED]1 and
[EMAIL PROTECTED] 2 when there are multiple keys, why not just make
the user genkey [EMAIL PROTECTED] 2 when they generate the new key?
Works for me, as long as monotone is consistent
Lapo Luchini [EMAIL PROTECTED] writes:
Richard Levitte wrote:
I won't deny that William's change is going to make a difference, but
I question if it will be *enough* of a difference.
IMHO as creation of more keys with same name will always be possible (in
disconnected spaces),
Ah, right.
William Uther [EMAIL PROTECTED] writes:
Let's look at some use cases here:
1a. A user makes a key. They commit some stuff and push it to
someone else. They lose their key. They decide to create another one
with the same name and try to use it.
1b. A user makes a key. They commit some
Matthew Gregan [EMAIL PROTECTED] writes:
The problem turned out to be pretty simple but kinda ugly. platform.hh
includes $platform/ssh_agent_platform.hh, where $platform is unix or win32.
The test to switch includes was using a non-existent define (WIN32_PLATFORM,
which is an Automake
I have a reproducible hang on Win32/MinGW during a sync file:. I've
saved copies of the two databases.
The command is:
mtn --debug --db /Gnu/monotone/tests/temp_2/gds-local-1.db sync \
file:/Gnu/monotone/tests/temp_2/gds-remote-1.db
Here's the last couple of transactions from the debug output:
1 - 100 of 981 matches
Mail list logo
