heads appear in
the same branch on the same machine will be the public repository.
Anyway, If that happens the commits are still there, just dangling
temporarily in no branch.
..for the mtn repo imported into git that is, right?
Regards
Markus Wanner (ne Schiltknecht
16.29 0.00
This leads me to think that the STL implementation doesn't provide an
O(1) implementation for size()... savings is avg memory consumption
seems to confirm this, no?
Other explanations?
Regards
Markus Wanner
___
Monotone
such as annotate with quite well populated
caches.
Anyway, sorry for the noise. I've just dropped the comment from NEWS.
Regards
Markus Wanner
annotate-a-ref.csv annotate-a-new.csv p
annotate-avg-resident-MiB 23.53 23.49 0.70
; something is
deadly slow. Would this tool help with that?
You can certainly run benchmarks over NFS as well. Although I'm not sure
how helpful that is. You are already saying it's deadly slow. What
difference does a benchmark value make against real world experience?
Regards
Markus Wanner
should have a look
at oprofile and try the exact mtn actions you want profiling data for.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
can affect when the memory usage is sampled and hence the estimated
memory usage.
Yeah, I've been questioning the 'avg' value as well. If you now tell me
that sampling is done at 1 second intervals, then I even suspect the max
value to not be very meaningful.
Regards
Markus Wanner
]). That alone is
a good reason to push the library-build branch.
Regards
Markus Wanner
[1]: benchmark results for sha1:
(using mtn benchmark_sha1):
default botan sha1: ~ 144 MiB/s
botan_sha1_sse: ~ 234 MiB/s
I've been unable to measure the amd64_asm variant, yet
Hi,
Markus Wanner wrote:
I've finally taken the time to go through upgrading the included botan
library to 1.7.12.
Sorry, I've forgotten the most important part: please test
net.venge.monotone.botan. I'd like to land that upgrade it on mainline.
Regards
Markus Wanner
for MinGW, but the machine finally died.
I may be able to get another one.
That would certainly be helpful.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
module) should be significantly faster than the C++ on non-SSE2 x86,
and maybe faster than the SSE2, but I haven't compared them yet.
Aha, good to know.
Thank you again.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
but leaves that task for 'make', making you fiddle with aclocal
in subdirectories if things don't work out as planned?
Comments?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
having upgraded (and now landed) monotone's included botan to
1.7.12. Jack is already approaching 1.7.15 with yet another set of
renaming. I'm rather going to use the nvm.stripped branch than continue
to manually upgrade again.
Regards
Markus Wanner
/botan/build.h did exist, so it should have found it, if
the -I flag had been passed to g++)
Any ideas?
Not so far, but I'll check the issue.
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman
Hello Jack,
Jack Lloyd wrote:
On Tue, Oct 07, 2008 at 01:10:55PM +0200, Markus Wanner wrote:
Hm.. you manually added 'botan-config' from /home/lloyd/.. to your PATH,
right?
Yes (and edited it slightly so it would produce the right output for
an in-dir build)
Are you sure this emits proper
as the changes don't conflict, the merge
algorithm does everything for you. Remember that branches are cheap.
Another way is to split logically different modules into different
files, which is advisable anyway, IMO.
Regards
Markus Wanner
___
Monotone
the program to be in
the future. But truthfully it will be a long time before it gets there.
You can also see why I am working on two things at once. Feature_A
usually is refactoring the code to make it modular, clean and correct.
Understood.
Regards
Markus Wanner
to use the provided botan :-(
I've removed my system wide botan and can confirm that the issue is
solved now. (As of e5f6d85442972da43d641bd3d7bf5d6667bbd23a).
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
think.
What's most important for me now is making monotone compatible with
newer sqlite versions.
Do you mind suspending these branches?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman
Hi,
Jack Lloyd wrote:
New version. Use the version macros for Botan instead of calling the
string function. Mostly for consistency with the rest of the version #
sources.
Thanks, very cool.
Committed as rev ce0db5b1f6d3b9ab45535784e298599733d0d6ab.
Regards
Markus Wanner
Hi,
I've now corrected or worked around issues with various sqlite versions.
These tests have failed before:
Markus Wanner wrote:
146 database_checkFAIL (line 23)
216 i_selectorFAIL (line 32)
Revision
Hi,
Markus Wanner wrote:
3.4.1 (what we shipped up to now)
Oops, revoking that. 3.4.1 and 3.4.2 currently fail on test
'database_dump_load', which is fishy because 3.4.1 was integrated
before, no?
I'm investigating on the issue.
Regards
Markus Wanner
not
require the hex() function.
I don't know how SQLite handles such cases, but I do know that not
paying attention to that kind of thing have and still can lead to
problems.
Agreed. Thanks for pointing this out. I'll check if we can add dynamic
version checks as well.
Regards
Markus Wanner
...
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
library is having to
use sqlite3_prepare() instead of sqlite3_prepare_v2(), which exists only
since 3.3.14. However, as that's just 1.5 years old and because 3.3.8 is
in etch, I'm trying to still support those versions.
Regards
Markus Wanner
___
Monotone
Hi,
Markus Wanner wrote:
Richard Levitte wrote:
Just a moment ago, I saw a change that made the montone code depend on
the version of SQLITE as described by a C macro. That's fine and
dandy provided you link monotone with the static library, but what
happens if it's linked with the shared
only. See: http://www.lua.org/bugs.html. That's why I made
nvm.stripped require lua 5.1.x (and not 5.0.x).
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
global lua variable).
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
(build time)
require 5.1.x anyway.
I've thus reverted to show only 'Lua 5.1' in rev
6b777e3eb453b3b0be4d9aaa93e81cd56c6ca635. (As opposed to showing the
patch version (i.e. 5.1.3) we've built against).
Regards
Markus Wanner
___
Monotone-devel
into testing all possible combinations of
library versions?
Certainly not *all* possible combinations. I'd say we don't even need to
test every single patch version of each library. After all, these
(should) provide a stable API and ABI.
Regards
Markus Wanner
still wondering why we (uhm.. Zack)
have implemented gmtime() from scratch. The comments tell something
about systems not using the Unix epoch. But which system? Are the
mktime() and gmtime() system functions really that unusable for portable
software?
Regards
Markus Wanner
on mainline?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
af1cd9d04a3cabab86dc14c8167ff5e83b26d6a6, I've reverted that to
using the system's gmtime() to gain a struct tm, which is independent of
the system's epoch. Instead of creating a date string from there, I'm
now using our own date_t::mktime() function, which is guaranteed to use
Unix epochs.
Regards
Markus Wanner
representation of date_t to use
(comparable) u64 seconds since Unix epoch, instead of storing strings.
Maybe I need to check for performance issues, but I don't think this
part is overly performance critical.
Regards
Markus Wanner
___
Monotone-devel
milliseconds.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Markus Wanner
[1]: full list of date mismatches:
mtn: checking timestamps of ancestor revisions
mtn:rev 006972c572eb094a3c03d3ea6105e7f31f5bfa05 - rev
c6bd5efd89266879cf9cbe7006b0fe5ca5d5b4dc
mtn:but date 2003-10-20T22:15:28 ! - 2003-10-20T21:38:09
mtn:(difference: 2239 seconds)
mtn
it
intersects with branch policy, and in part because I'd really like to
think of a nice way to make it work for revision encryption too..
Sounds very much like something that could work together with policy
branches, no?
Regards
Markus Wanner
___
Monotone
Markus Wanner
-
Revision: 4dd538bd7bb906041b817b8bc6a93e87fb3759d5
Ancestor: ee293e066aa9e8222b7ce3b854affe49ddf9317c
Ancestor: ee5efcb81167e04e6c915ce21bb32b832b7ad964
Author: [EMAIL PROTECTED]
Date: 2008-04-30T15:32:06
point.
However, it *should* not be necessary to create and drop keys for that,
but instead just adjust keys to trust, possibly limited in time.
Hopefully we get there with your policy branches, one day... :-) I must
admit that I still didn't look at your branch...
Regards
Markus Wanner
harmful for all others as well,
as you make it sound.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
now and then
are pretty low here. I could only attend half a day or so.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
. Once we use hashes for keyids that is.
Huh? How should that be possible? Isn't it sufficient exchanging known
public keys during netsync?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org
or not... ;-).
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
identity remained the same. I simply
added my new name, now having Markus Schiltknecht and Markus Wanner
as names for my identity.
the guy who owns this key
.. that's exactly the identity part of the story. Just replace this
key with a GPG key and you could theoretically throw away monotone
keys
for the (unmaintained) netxx?
Anybody used boost::asio before?
Thoughts? Comments?
Regards
Markus Wanner
[1]: Nathaniel: boost::fs is slow:
http://article.gmane.org/gmane.comp.version-control.monotone.devel/4262
___
Monotone-devel mailing list
Monotone-devel
, the assumption is good enough to provide that
convenience feature called date cert.
To help the user making that convenience feature more reliable, it would
help if monotone checked date certs, IMO, without hurting anything else.
Regards
Markus Wanner
seconds, and hence is monotonic.
Conversion between UTC and local time is pretty simple on most systems,
where as UTC to TAI and back is not as common.
IMO the user shouldn't need to care about anything except local time.
Regards
Markus Wanner
___
Monotone
think we should warn there.
Even make hints about clock skews. Why is that so unwanted for monotone?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
?
Anyway, I think there's enough resistance to drop the idea for now.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
, see below for examples - no
warnings, no further checking, only db info is affected. I've
committed that into a separate branch nvm.dates.statistics. Please
review as well, I consider that to be ready to land on mainline, too.
Regards
Markus Wanner
Here's the relevant additional part of db info
.
Cool, thanks for this opinion.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
.
Agreed.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
is currently sufficient for my needs WRT dates.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
, at the moment it would involve unwanted UI uglification. So I'm
postponing this proposal until we have policy branches :-)
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
as C++. If we don't require stack unwinding on
error (I have not looked at the code), then dynamic linking is fine, but
I think this is a candidate for bundling.
I'll check this issue.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone
Hello Jack,
Jack Lloyd wrote:
I would really like to get 1.8.0 out the door before the end of the
year. We'll see.
Sounds fine to me. Thanks for the overview.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
libraries. (And I'm curious if you can get
nvm.stripped to compile on MacOS X. ;-) )
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
for propagating lua
errors back to the monotone user, just like loading failures.
There are not many tests for such thing, are there? I didn't find
neither unit nor lua tests.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
or feature.
I suspect that's because there is no system library naming convention
that distinguishes between otherwise identical libraries, one compiled
with C++, one with C.
Object symbols are also different.
Regards
Markus Wanner
___
Monotone
distclean' and probably re-run the autoconf
toolchain?
I've upgraded the included botan version which carried some renames and
such. But I didn't test on Win32.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
to object to landing this on mainline either. Some of
the stats could be useful; frequency of checkins might correlate with
something :).
Hehe... yeah. :-)
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
a good point as well. So we don't only need to pay attention
to the lua - mtn boundary, but also the other way around, when lua
calls back mtn. Thanks for that hint.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
before 1970, which is a pretty common
boundary. I don't see much reason to add support for that now, either.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
the changes to Makefile.am with minor adjustments and
some comments on these exceptions. Thanks for your report and please
test again.
All in all I'm really looking forward to nvm.stripped to get rid of
these custom build harness issues. Do you mind test building that
branch on MinGW?
Regards
Markus
by using a stand-alone Lua copy or by compiling a tiny
piece of C code that links against the library and execute it on the
machine.
Agreed.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman
want to try various LUA_CPPFLAGS (or was it LUA_CFLAGS, I
don't remember...).
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
differences
to them. IMO this has already taken way too long and we should better
spend our dev-time on more relevant things.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo
Hi,
Markus Wanner wrote:
Agreed, renamed to millisecs_since_unix_epoch().
Hm.. this isn't used anywhere, since date_t::operator-() is sufficient
in all cases so far. So we might even drop it.
Regards
Markus Wanner
___
Monotone-devel mailing list
Hi,
Lapo Luchini wrote:
Other people? Comments?
December doesn't work for me anymore... sorry.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
I'm not
particularly found in m4.
I'll have to get my MinGW buildbot back on line; the video output
died, so I need to get a new computer.
Having a MinGW buildbot would certainly be cool.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone
in the know:
* what's missing on the new ikiwiki?
* what does it take to switch to the new one?
* what does it give us, that the former one didn't?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
probably all Debian, but none the less...
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
the test suite. Again, strip it!
Well, we could add a future process section to the wiki. But this is
moot, since the wiki is currently not editable.
Good point. What's up with the wiki? Let's start another thread for that
question, though...
Regards
Markus Wanner
Hi,
Lapo Luchini wrote:
What about 17th-18th January 2009?
Works for me as well. Although I cannot promise to be available all
weekend long.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org
it. It rather looks like
botan offers something similar to benchmark various sha1 engines. I
didn't look into that, though, but don't think we need to duplicate that
work.
nvm.stripped now compiles fine and passes all tests again.
Regards
Markus Wanner
monotone 0.41 (base revision
because such a benchmark
might not pay-off every time mtn is invoked. Alternatively have it
stored in monotonerc and set as a system config during installation of
monotone. Storing in _MTN/options sounds easier to automate, so I'm
currently favoring that variant.
Regards
Markus Wanner
been considered, but argued against, because stat() should be
fast and simple enough.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
this as well, but haven't been able to reproduce
it either. A glibc error is rather bizarre, IMO.
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
with reasonable efforts.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Hi,
Stephen Leake wrote:
If you are refering to the conflicts resolution stuff in
nvm.resolve_conflicts, that has already been merged into main.
Oh, I missed that. Sorry for the noise, then.
Regards
Markus Wanner
___
Monotone-devel mailing list
is, that ./configure still says:
...
checking whether NLS is requested... yes
...
(as long as I don't manually give --disable-nls). So I'm guessing my
glibc is still compiled with nls. How do I check?
Regards
Markus Wanner
___
Monotone-devel mailing list
is maintained in case of throw usage(), I'm
fine. I dislike tools which just throw the complete usage page at me and
let me figure myself. Some hint on what's wrong certainly helps. And
that hint should survive, IMO.
Regards
Markus Wanner
___
Monotone
proposes? Clearer separation of the two.
2. N() is not the best choice for handling this to begin with.
Agreed. Timothy proposed using throw usage(); instead, which is
according to these two requests, AFAICT.
Regards
Markus Wanner
___
Monotone-devel
Hello Timothy,
Markus Wanner wrote:
Ralf S. Engelschall wrote:
| mtn: peer monotone.ca IO failed in confirmed state (success)
| mtn: successful exchange with monotone.ca
I can reproduce this on a i386 FreeBSD 6.4 and will try to hunt the bug
- sometime this month. Thank you for reporting
help?
# USE=-nls emerge glibc
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
.. yeah. I'll try the hardened variant, cannot hurt to have such a
hardened buildbot...
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
comment on
writing mtn git_import? Problems we are facing there?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
won't have time to look into this again
anytime soon.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
an import and
export group is equally stupid.
Sorry if that didn't get clear, but I'd vote for the smallest change for
now. (IMO, that means leaving cvs_import and git_export, but put them
into a single command group).
Regards
Markus Wanner
___
Monotone
with a
custom lua command...)
I absolutely agree.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
.
However, most other VCSen I've seen so far do not allow such a thing.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Hi,
Markus Wanner wrote:
Barry any objections I plan to land both tomorrow.
net.venge.monotone.dates.statistics
(and therefore net.venge.monotone.dates)
have just landed on mainline.
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone
there are enough other bugs ;-)
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
suite for 0.42?
rant I'm trying to get MinGW installed, but Windoze is so damn
uncomfortable! /rant
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
on polish locale is 3,4 grrr
They are: 1. minor, 2. unrelated
I forgot to report them never mind having time to fix.
Can you reproduce what the OP reported?
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
pulling, pushing and syncing databases?
Please read UPGRADE and/or NEWS.
AFAICT there have not been any netsync incompatibilities since at least
0.25.
For database schema changes, a simple mtn db migrate should do the trick.
What does mtn version --full and mtn db info give?
Regards
Markus Wanner
Hi,
Thomas Keller wrote:
Anyways, the error is quite common and unfortunately won't be fixed any
time soon.
Let's at least say: we should try to improve the error message. Do we
have some sort of TODO file or something? Or is this a summit'09 task:
to organize todo items?
Regards
Markus
1 - 100 of 347 matches
Mail list logo
