Yury Polyanskiy wrote:
Please consider this bug... It always causes problems when updating
upstream releases: you update, make a tag then realize that something
was missing and you have to add the tag again.
Hm.. I see your point. However, there is 'mtn add --recursive', which
you might want
Hi,
Thomas Moschny wrote:
Markus Schiltknecht wrote:
Can you please be more specific? Which three versions of the same file
are you referring to? I only see two [...]
Ok, here's the graph again. But be warned, we need a lot of characters ;)
A: 1,foo,v B: 2,foo,w
Hi,
William Uther wrote:
An example: how is bob expected to resurrect a file foo, which got
overridden by another node id which is now called foo. I can only
think of something like take file 'foo' from rev '1234..' but name it
'bar', which will quite certainly make bob become crazybob.
Hi,
Stephen Leake wrote:
It depends on the user's intent; there is no way for monotone to know
what the right thing to do is here.
Full ACK.
One example of user's intent is here is the thermostat use case. C
is an early attempt to use one file to provide both the Honeywell and
Westinghouse
Hi,
Matthew Nicholson wrote:
I suppose that could be a little complicated, but as you said it could
be something like:
mtn ls dead foo
mtn resurrect a1b2c3f foo
The ls dead command would show dropped nodes by file name and the
revision they were dropped in, the mtn res command would
Hi,
Thomas Moschny wrote:
There can, that's what suturing is about.
Not if suturing conflicts with renaming and dropping, which prevents
such a merge with certainty. That's the point of my proposal and why I'm
thinking it's simpler (to implement as well as for the end user).
Because it
Hi,
Jack Lloyd wrote:
On Thu, May 08, 2008 at 09:48:14AM -0700, Eric Anderson wrote:
Markus Schiltknecht writes:
Eric Anderson wrote:
Revision: 464e510af4959231ff63352c902c689b0f1687aa
Branch: net.venge.monotone.experiment.performance
Hm.. why didn't any of this get merged
Hi,
William Uther wrote:
o
/ \
a b
/ \ / \
c d e
\ | /
\ | /
f
Let's check for merging c and d: common ancestors are: o and a,
clearly, a is lower, so that's the LCA. Doing a 3-way merge with that
should work just fine. Say that merges into g.
If
Hi,
Stephen Leake wrote:
This is the same duplicate name conflict that was noticed when merging
a and b to get d. So merging g and h fails with a duplicate name
conflict, and 'merge --resolve_conflicts' lets the user resolve it,
by another suture.
Huh? Out of c, d and e, which we are merging,
Hi,
Thomas Moschny wrote:
[...]
but:
0 file a exists
/ \
1 3 file a is changed (differently in both 1 and 3)
2 4 file a is deleted (both in 2 and 4)
\ /
5
6 file a is resurrected
Which version should mtn resurrect? (it could ask the user, but we
don't do that for
Hi,
Thomas Moschny wrote:
Markus Schiltknecht wrote:
You might even have renames, so that the file to be resurrected isn't
currently visible. How's the user supposed to resurrect the file then?
Now I lost you ;) Resurrection is about bringing dead files back to live, so
it will always
Hi,
Thomas Moschny wrote:
Agreed, but in the example, this is not the case anyway. The only thing I said
was: *If* we implemented suturing as drop,drop,add (all within D), and not
cared about the relationships between the newly created file and its
predecessors, then there were no conflicts
Hi,
Thomas Moschny wrote:
Markus Schiltknecht wrote:
Thomas Moschny wrote:
However, we simply can't do that. We can't go back and treat two
different file identities as a single one. Well, we can do it, locally,
but only *as soon as we know about the users wish to do so*. And the user
in turn
Hi,
Eric Anderson wrote:
Revision: 464e510af4959231ff63352c902c689b0f1687aa
Branch: net.venge.monotone.experiment.performance
Hm.. why didn't any of this get merged into mainline? Looks like there
are more good ideas lying around in that branch.
I will have a look at the binary rosters
Hi,
William Uther wrote:
I can't see an easy way to implement this without a graveyard. If you're
going to implement a graveyard, then I'd get rid of DieDieDie merge first.
Hm.. I don't see what file resurrection has to do with suturing. Of
course, resurrection would help the user to revert
Hi,
Thomas Keller wrote:
On the summit we talked about a way to let the server block clients
(f.e. through a lua hook) which do not fulfil certain version criteria.
This would, however, need a change deep inside netsync, because mtn does
not exchange these data. It would not change much for
Hi,
Justin Patrin wrote:
I'm thinking of suturing as an atomic delete two, add one operation.
Except, of course, that the history points to both the deleted nodes,
causing merging and such to work properly, correct? It seems to be
that implementing this as 2 drops and 1 add could be
Hi,
William Uther wrote:
Superficially, suturing and resurrection have nothing to do with each
other. However, if you implement suturing using drop, and you still
have DieDieDie merge, then suturing is a VERY dangerous operation.
Suturing (as I currently understand it - based on drop) would
Hi,
Thomas Moschny wrote:
A B
/ \ /|
| X |
| / \|
| C D
|/
E
Suppose A has add foo, B has add foo, D is a simple merge, so
D contains a single sutured file name foo. Suppose also that C
has rename foo bar, and E is a simple merge, so E
Hello Stephen,
sorry, I still didn't get around reading your initial plan on how to
handle non-content conflicts. It's great you are taking care of this!
Stephen Leake wrote:
The use case is that a file with the same name is added on two
different heads (or branches), and then the heads are
Hi,
Christof Petig wrote:
The problem at hand is the malloc and memset overhead introduced by
using a dynamic buffer.
Huh? Why do we use memset there? malloc() hardly makes for a 40%
speedup, does it?
The botan decoder might as well be used by the specialized functions
which give 40%
Hi,
Lapo Luchini wrote:
That's my line too, and also of thm as far as I understood.
Problem is: changing the roster format is more difficult than optimizing
de {en,de}coder of course ;-)
Well, yeah, it's difficult because our current basio_io isn't basic
enough to support binary contents.
Hi,
Ludovic Brenta wrote:
It seems to me that, if the node ids were content hashes, it would solve a lot
of problems. For one thing, creating two identical files would yield the same
node id. For another, creating two different files with the same name on
different branches would become a
Hi,
Stephen Leake wrote:
one file, or the files should be renamed to different files.
Currently, suturing is not supported, so we approximate it by
dropping one file, and manually merging its content with the other
file.
Hm.. isn't approximation by renaming simpler? That way, you'd just
have
Hi,
Stephen Leake wrote:
No, the two choices are suturing vs renaming. They reflect different
understandings of the purpose of the added files.
Aha, okay.
Here are my two canonical examples:
Renaming: Beth and Abe each start working on thermostat models; Beth
on a Honeywell thermostat, Abe
Hi,
Christof Petig wrote:
I tested Thursday's net.venge.monotone with binary ids and I don't know
about cached pipes. But this should be easy to speed up (especially
given that, according to Lapo, there is/was a specialized 40 digit hex
decoder in monotone written by Graydon.
Ah, okay, so
Hi,
Christof Petig wrote:
just some notes for myself on the performance problems with OE:
- - hex_decode is used extensively by roster.cc: parse_marking (and
expensive)
- - get_roster_version is taking 90% of the time
- - hex_decode is taking 25% of the time
- - hex_encode is taking 15% of the
Hi,
Koen Kooi wrote:
Well, git has this feature:
An example from man git-push:
--force
Usually, the command refuses to update a remote ref that is not an
ancestor of the local ref used to overwrite it. This flag disables the
check. This can cause the remote repository to lose commits; use it
Hi,
Lapo Luchini wrote:
Is that some sort of German shmoo[1]?
Mh.. not quite. But you should have enough Germans around you to explain
to you ;-)
It's one of those very powerful and efficient animals which produce eggs
(Eier), Wool (Wolle) and Milk (Milch) and which - after slaughtering -
Hi,
Thomas, can you elaborate on the state of this http/json webservice you
are refering to here:
[EMAIL PROTECTED] wrote:
-
Revision: 63a44f0a3ebbed02b4426db2edd700c5a7b03a2f
Ancestor: a74ba5f609a7b7fcd881cea6dece6bcd7beda053
Hey Thomas,
Thomas Moschny wrote:
It's simply that I realized that forking off and talking to a monotone
subprocess from within the trac plugin is not the best thing to do, for
several reasons:
Sorry, I wasn't questioning your motives. It makes perfect sense to me...
Can I run a standalone
Hi,
I'm sorry I cannot attend this year's monotone summit. I tried to get
some days off, but we just have too much work to do here and my
co-workers didn't want to let me go :-(
However, I'll try to be with you on IRC and wish you all a lot of fun
hacking monotone. Also don't forget to
Hi,
Richard Levitte wrote:
The only thing that I see might need a flag day of all those things is
this mega-cert change, which I'm not sure is needed, relatively
speaking.
(Assuming we want atomic certs) I'm thinking about splitting that task
up into two: one is the internal change of the
Hi,
Zack Weinberg wrote:
We really need a scheme for versioning the algorithm used to digest
and sign a particular object. If we had that, then it would be
possible to continue checking signatures on old objects in the old
way, but use the new algorithm for all new objects.
I absolutely
Thomas Keller wrote:
I'd keep revision_certs as a local cache of cert blobs which are
stored elsewhere (revision_certs_blobs?!). Otherwise we'd have big
problems with fast lookups of revisions via their certs (i.e. select).
Yeah, that's something I've also been thinking about. However we do
Hi,
Stephen Leake wrote:
I think it would be better to store the key in _MTN/options if
--set-default is specified on the 'pull' command line, and then also
use the key from _MTN/options if it is there.
That's easy to implement; I just did it for sync.
Well, that reduces the problem to
Hi,
I've finally got around playing with that branch again. Some remarks below.
Zack Weinberg wrote:
Monotone itself has been moved to
another subdirectory (currently named monotone, but I could be
persuaded to rename it src or something like that).
+1 for naming it src.
The top-level
Hi,
Zack Weinberg wrote:
As best I can tell from reading the sqlite releases page [
http://sqlite.org/changes.html ] there are no on-disk format changes
between the version we have and the latest one.
Looks like I've misread the warning from their migration page. See
Hi,
Ralf S. Engelschall wrote:
Hmmm... well, I think it would not matter very much whether we use the
amalgamation or the regular SQLite. The amalgamation perhaps has the
advantage that it is less intrusive to the Monotone source tree and
that a theoretic compiler code optimization advantage
Hi,
Zack Weinberg wrote:
On Sat, Apr 5, 2008 at 12:37 PM, Zack Weinberg [EMAIL PROTECTED] wrote:
On Sat, Apr 5, 2008 at 6:41 AM, Markus Schiltknecht [EMAIL PROTECTED] wrote:
I was trying to keep the current, stripped botan variant, so as to keep
changes to a minimum. That one gets
Hi,
Zack Weinberg wrote:
Right now what works is building idna, lua, netxx, and pcre. My
original intent was to have these be verbatim upstream tarballs but
that proved impractical, I've pretty much written my own Makefiles and
configure.ac's for all of them. [Only idna and pcre have upstream
Hi,
Ralf S. Engelschall wrote:
The alternative is to place a full SQLite build-environment 1:1 into
sqlite/ and also run its own configure step during Monotone's
configure step.
Yes, that's what I've been talking about and what nvm.library-build is
all about.
No, the amalgamation
Hi,
Jack Lloyd wrote:
Monotone uses EMSA3 (aka PKCS#1 v1.5), which is a deterministic
encoding. So for a fixed input, the same key will always produce the
same signature. (The generally accepted solution for RSA signature
padding is EMSA4 aka PSS, which is a randomized method).
Sorry if this
Hi,
Richard Levitte wrote:
Not a problem in my opinion.
Okay, I've now propagated nvm.experiment.db-compaction to mainline.
Regards
Markus
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
Hi,
Julio M. Merino Vidal wrote:
However, I assumed that 'mtn pull' should do the right thing for any
subsequent pull but it does not. It correctly remembers the branch
and pattern but it insists on doing anonymous pulls. Should these
secondary pulls also reuse the key used for the initial
Hi,
Jack Lloyd wrote:
Wouldn't it make sense though for a pull to (if nothing else) retry
using available keys if anonymous access were refused? (Ie, why make
the user do it when Monotone can easily guess).
Sure. That has been proposed before, and we know it would make sense.
However, nobody
Hi,
Ralf S. Engelschall wrote:
While looking at compile-time warnings of Monotone, I've just stumpled
over the fact that we are still using SQLite 3.4.2 in Monotone while at
sqlite.org we already have SQLite 3.5.7 released recently. My simple
question is: what is the official Monotone upgrade
Hi,
Derek Scherger wrote:
I also think that in the directory is much better than the earlier
for the directory myself. The latter hints that the directory is in
conflict, rather than the thing in the directory.
Yeah, right. That's one of the nitty gritty details only a native
speaker can
Hi,
Stephen Leake wrote:
Logically, those are not branches; they are now part of mainline. So
it would be more correct to say :
I don't quite follow your reasoning here. Even if they got merged later
on, those are still branches of development.
You will get revisions that used to be
Hi,
Markus Schiltknecht wrote:
during this easter hack, I've managed to get further with
nvm.e.db-compaction. Rememder? The branch turning all database and
in-memory ids into binary representation.
Anybody opposed to landing that branch before releasing 0.40? If nobody
speaks up I'm going
Hi,
Koen Kooi wrote:
And what about mtn resolving NCCs for people, instead of erroring out
with a nicer message? bogus invariant or nice error message still
don't get me a solution to the problem, it just makes me throw a smaller
object out of the window ;)
Well said ;-)
We certainly have
Hi,
Zack Weinberg wrote:
On Sat, Mar 29, 2008 at 11:16 AM, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Anybody opposed to landing that branch before releasing 0.40? If nobody
speaks up I'm going to merge it back to mainline on Monday, okay?
No objection from me. I've checked in a few more
Markus Schiltknecht wrote:
Do you mind enclosing the URL scheme you are using here?
Uh.. s/enclosing/disclosing/ :-)
Markus
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Hi,
Koen Kooi wrote:
Since it's read-only, is it possible to cache the state and allow
multiple connections?
Hm.. if it uses mtn automate behind the scenes, as I did in my
experiments, I fear that makes not much difference. (Except nuskool
being faster than netsync anyway.)
At
Hi,
Thomas Moschny wrote:
Of course. However, I retain the right to change them if they turn out to be
not as useful as I thought :)
Hehe.. :-)
/revision/REV_ID
/manifest/REV_ID
/certs/REV_ID
/file/FILE_ID (raw)
/branches
/tags
/revisions/leaves
/revisions/roots
Hi,
Ralf S. Engelschall wrote:
As Monotone is already using its own build-environment
..which is a bad thing(tm), which we want to get rid of, IMO...
for building the
sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to
just the sqlite3.[ch] files from the SQLite
Hi,
Thomas Moschny wrote:
There is not something like a REST standard, but as far as I understood, URLs
for a restful service should start with a noun denoting what is returned by
that URL, and followed by some id (or, in the case of returning a set, some
other arguments to further confine
Hi,
Matthew Nicholson wrote:
I don't like this idea. One of the things I like about monotone is that
it does not force you to think like its developers think when it comes
to naming branches. As a side note, I do like '.' as a branch
separator, but not the reverse domain name prefixes (I
Hi,
Marcin W. Dąbrowski wrote:
And that's what I call fast reaction! :) I just love opensource
model of support... You guys just rock!
Thanks, nice to hear that!
Naah, just 3+ years of corporate QA experience made me such
a bugreport monstah. :D
Hehe.. :-)
So, I don't want titles, I'd
Hi,
Zbynek Winkler wrote:
conflict: duplicate name 'x' for the directory
named 'bar' on the left and
named 'foo' on the right.
That suggests (at least to me) there is a conflict in the name of the
directory and not in a name within the directory. But it could be that
I
Hi,
Thomas Moschny wrote:
Which brings me to the question: Why don't we abandon this serial
interface-revision number at all, and replace it with a keyword-based
capabilities string resp. list?
Without having read all of this thread, that feels like a good thing to me.
Markus
Hi,
Thomas Keller wrote:
I translated name to the German word for entry, so an improved
message could be
conflict: duplicate entry 'x' in the directory
named 'bar' on the left and
named 'foo' on the right.
Hm.. I'm not sure I consider that an improvement. One can argue
Hello Marcin,
Marcin W. Dąbrowski wrote:
Today I was playing with monotone 0.39 a bit, and by a mistake
I've triggered 'something' - maybe a bug, at least monotone says so.
Hm..
http://twine.pl/tmp/mtn-roster-merge-bug.zip (20 KiB)
Wow, thanks a lot! If only all bug reports were so
Hi,
Brian May wrote:
I don't understand this; I thought Monotone only considered two file/dir
to be the same if they shared a common ancestor. In this case, it would
appear both files have different ancestors, and the filenames are
different at the time of merge, so I don't see why they
Hi,
Thomas Moschny wrote:
Yes (...without /all/ of its certs).
I know that certs are loosely coupled to their respective revision.
Nevertheless, it is unexpected to get, during a sync, a revision, and all its
other certs, but not its branch certs (which in turn shows, that there must
be
Hi,
Nathaniel Smith wrote:
Yeah, touching $HOME is weird, we should be using --confdir or
whatever it's called... that said, setting HOME to something isn't
*too* crazy a way to sandbox the mtn-under-test.
But if we do go that way, we'd better set APPDATA too...
The reason I was fiddling
Hi,
Stephen Leake wrote:
I think Markus' fix is better. Then we can also put specific stuff in
the $HOME directory, to test the behavior in those cases.
We should experiment with adding that $HOME fix to the core 'safe_mtn'
command; carefully, of course :).
You mean, as a general test case
Hi,
to get into autoconf et al, I've played around with the library-build
branch. Hope Zack doesn't mind... :-)
I've reverted botan to its own directory layout, using its configure.pl
script. I'm not sure invocation of that perl script is correct in
configure.ac, however, it seems to work.
Hi,
Timothy Brownawell wrote:
push/pull/sync are not GET/PUT/DELETE operations, they need a lot of
negotiation to find out what to send. They cannot be directly supported
by dumb servers, you need a smart client with the necessary logic to
break them down into simpler parts.
I fully agree.
Hi,
Thomas Moschny wrote:
Any time this comes up, I wonder again, what was the argument for including
revs that are ancestors of revs you want to sync, but at then excluding their
branch certs? I always found this counterintuitive.
I think that's just an effect of how netsync works, with its
Hi,
Thomas Moschny wrote:
Would you mind adding some words to NEWS about this, and especially about any
positive (or negative?) impact this might have on the end user or on clients
using the automation interface? Will all or some of the locking issues go
away in 0.40?
Thanks for the
Hi,
Thomas Moschny wrote:
Ok. I vaguely had in mind that there also was a non-technical reason.
I don't know any non-technical reason.
Exactly, but that's why I said it looks like an ugly hack. It fixes the
problem accidentally, ...
(For the common case of syncing net.venge.monotone,
Hi,
Thomas Moschny wrote:
For the end user, this change should not have any noticeable effect,
except mtn being a tiny bit faster and the database taking somewhat less
space. Every other difference in automate or locking behavior should be
considered a bug. :-)
Oh, sorry, I've been talking
Hi,
Zack Weinberg wrote:
I should mention that there's an as-yet-unimplemented change I wanted
to piggyback on the db-compaction branch which would have had
user-visible consequences -- eliminating the use of IDNA for various
in-database strings.
Hm.. does it really make sense to piggyback
Hi,
Zack Weinberg wrote:
Hm.. does it really make sense to piggyback those to db-compaction? That
branch already contains way too many changes, IMO, so I'd vote for doing
that in a separate branch.
I had two reasons: it gets awkward to have multiple outstanding
branches with schema
Hi,
I've hopefully fixed the two tests, which were failing on mainline. The
first, non_workspace_keydir, one was failing, because it expected no
keys in the keydir. If you had some in $HOME/keys, it failed. I've
solved this by creating an empty directory and setting $HOME to that.
I'm not
Hi,
Philipp Gröschler wrote:
Have it look like
http://venge.net/branch?net.venge.monotone
That would be fine, if all servers were clever ones. But there are
pretty dumb ones out, and I'd like to support them as well. Preferably
with the same syntax.
and the parsing on client side should
Hi,
Timothy Brownawell wrote:
For ssh transport the remote system would have to send back the db path
it found, so we'd know where in the URL to start looking for parameters.
Putting parameters into the query string instead of appending them to
the path gets around this rather nicely.
That's
. ]
Derek Scherger wrote:
Markus Schiltknecht wrote:
Then, there are the planned nuskool commands. Those are currently
encoded entirely in JSON. The HTTP client requests the same URL every
time, and encodes the query in JSON. ATM nuskool doesn't support
branch inclusion or exclusion patterns
Hi,
during this easter hack, I've managed to get further with
nvm.e.db-compaction. Rememder? The branch turning all database and
in-memory ids into binary representation. It now passes all unit tests
except schema_migration as well as those which are currently failing on
mainline as well.
Hi,
Zack Weinberg wrote:
Actually, can we reserve / to refer to something - revision or
versioned file - *inside* the branch(es) selected? I know this
doesn't make any sense with the existing protocol, but maybe it would
later, so it seems to me wisest to reserve space in the URL schema for
Hi,
Timothy Brownawell wrote:
All of these should work:
mtn sy monotone.ca net.venge.monotone* --exclude *experiment*
mtn sy mtn://monotone.ca?net.venge.monotone/-*experiment*
Shouldn't this have been:
mtn sy mtn://monotone.ca?net.venge.monotone*/-*experiment*
Without the asterisk, the
Hi,
since I've been critiquing Timothy's current extensions of the URL
scheme, I think I need to try coming up with something better. Or at
least help in doing so. First of all, I've put together a list of URL
schemes we are using in and around monotone, including nuskool, which
probably is
Matthew Nicholson wrote:
Personally I think that looks horrible and confusing vs the --include
--exclude syntax. The variant that has ?include=patternexclude=pattern
is slightly more readable, but I still prefer the command line switches.
+1
Markus
Hi,
Timothy Brownawell wrote:
It will be in addition to the current syntax, so what works now will
still work.
Okay, that's fine.
Yes, '' and especially '!' aren't good characters for shells. I think
I'll use the suggestions of '/' and '-' instead (still in the query
string instead of the
Hi,
Nathaniel Smith wrote:
On Thu, Mar 20, 2008 at 07:38:25AM -0400, Stephen Leake wrote:
We're porting monotone to the Lynx operating system. So far it passes
the first set of unit tests.
The problem at the moment is this error:
fatal: Botan::PRNG_Unseeded
Basically, this is a question
Hi,
Richard Levitte wrote:
It seems to be that part of the month, doesn't it? In Sweden, the
25th is the day you usually get your monthly paycheck in Sweden, and
why not get a release at the same time? ;-)
But I digress...
Anyway, it seems like we need to settle the whole mtn:// matter
Hello Jack,
Jack Lloyd wrote:
Problem: Visual Studio (and I think other Windows compilers) will
accept a bare 64-bit constant, but don't understand a LL/ULL suffix,
and will halt the compile. So the needed thing is something like
#if __GNUG__
#define LL64(x) x#ULL
#else
#define LL64(x)
Hi,
Stephen Leake wrote:
Markus Schiltknecht [EMAIL PROTECTED] writes:
Please check if nvm.botan runs on your machine. On my machine, the
compiler warnings on 32bit machines seems to have gone with 1.7.4.
Works on Win32 MinGW
Cool, thanks for testing.
Markus
Hi,
Markus Schiltknecht wrote:
Hm.. yeah, I've set that flag for all 3rd party libraries now.
Uh, sorry, I'm revoking that - it looks like it's not needed for botan
1.7.4. So I prefer not to add that flag for all 3rd party libraries.
Markus
Hi,
since botan 1.7.4 features some speedups for sha1, I thought I'm
upgrading the monotone provided version right away. It is done as usual,
see botan/README.botan-monotone.
Please check if nvm.botan runs on your machine. On my machine, the
compiler warnings on 32bit machines seems to have
Hi,
Koen Kooi wrote:
As the subject already hints at, OpenEmbedded is seriously looking at hg
and git because mtn can't merge any of our branches due to non-content
conflicts (ncc).
Oh.. that makes me wonder how hg and git handle non-content conflicts.
Of course you are going to reply with
Hi,
Zack Weinberg wrote:
Given this, it occurred to me to try to cache constructed Pipe
objects, so that we avoid both the locking overhead and all other
construction overhead, in particular heap-allocation of memory blocks
c.
Uh.. isn't simple hexenc_{en,de}code also affected by this? That
Hi,
Markus Schiltknecht wrote:
since botan 1.7.4 features some speedups for sha1..
Comparing botan 1.7.3 with 1.7.4, monotone gives these sha1 throughput
numbers on my laptop (Intel Core(1)Duo):
1.7.3: 90.91 MiB/s
1.7.4: 94.43 MiB/s
Regards
Markus
Hi Zack,
reading the commit ML, I've taken notice that you propagated to
nvm.experiment.db-compaction as well. Just some quick notes from my side
to avoid duplicate work.
I've started to migrate to an internal binary representation of hashes,
the complete id now means a binary id, and only
Hi,
I've just propagated from net.venge.monotone.botan to nvm. This brought
an upgrade from botan 1.7.2 to 1.7.3.
Regards
Markus
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Hi Zack,
Zack Weinberg wrote:
I consider the work on nvm.experiment.encapsulation to be done, and I
will merge the branch to mainline once the release happens. There are
still some awkward places e.g. in the key_store and the restrictions,
but not enough to keep this dragging out any longer.
Hi Richard,
Richard Levitte wrote:
I must have missed a discussion
Find the discussion here:
http://lists.gnu.org/archive/html/monotone-devel/2007-05/msg00185.html
so if anyone can fill me in on the
.gaps branch (with these things called sentinels), I'd appreciate it,
or even better, write
Hello Stephen,
Stephen Leake wrote:
Windows MinGW is an important platform (because of the number of
users), and it has essentially no distribution package manager (just a
SourceForge site), and no pcre package at the moment.
Agreed. And how's the Visual C++ build doing?
On the other hand,
Hi,
Kelly F. Hickel wrote:
[Kelly F. Hickel] (just responded a minute ago to an earlier one). I
think it works fairly well, there are 2 or 3 tests (IIRC) that don't
pass, someone who understands what they are supposed to be doing needs
to look at them. Every now and then someone commits a
1 - 100 of 411 matches
Mail list logo
