[Monotone-devel] Re: MtnSummit 2008
Lapo Luchini wrote: Let's start with this: EVERYBODY FILL IN AVAILABILITY-DATE TABLE! http://www.venge.net/mtn-wiki/MtnSummit2008 ...so that we can decide it (and thus book tickets) shortly ;-) Everybody did? IMHO we should begin to talk about actual dates... (which can, in turn, help people decide to participate, like I kinda remember it was last year..?) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] As you probably noticed, the release got delayed...
Hi, Some of you must have noticed that I didn't keep my own schedule. The reasons are many, and one of them is that I wanted to give the currently latest Debian package (0.37-4) time to trickle down into the [testing] distribution. I'll take a look at available information later today and will decide on a release date accordingly. Anyway, I would like to have some verify that NEWS is synchronised with the actual changes made since 0.37, as soon as possible. Thanks, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Patches and questions to various automate commands
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all!
Some questions on several automate commands:
automate genkey:
-
Apparently this command outputs status infos on stderr, which is totally
unexpected when used over stdio. IMHO only stdio itself should directly
output stuff over stderr - if commands need error output, they need to
ensure this gets encoded into stdio.
Any objections against applying the attached genkey.patch? The only
thing I'm wondering here is if I should push the interface_version here
- - while the status output is certainly not part of the documented format
it outputs, it was just there since 4.1 ...
automate keys:
- --
A small little glich I encountered just recently: A running mtn
instances won't notice if a key has been dropped from the keystore
because it reads the local keystore only once (maybe_read_key_dir() in
key_store.cc). Now, I _think_ the whole key_store caching thing is a bad
idea at all because there is at least one other command I know (automate
cert) which now runs over stdio and needs an up-to-date key list as
well. However, I have no idea if its really a good idea to completly
remove the keystore cache as I did in keystore.patch.
automate db_get:
-
No patch yet, just wondering here if it would be a good idea to change
this command in the way `ls vars` works? Problem I'm facing here is that
one f.e. cannot guess the name(s) of the known servers to get their
fingerprints. I'd likely change the output format of db_get to some new
basic_io-based format and output everything just like `ls vars`. Would
the name db_get be anymore good then for this or shall I rename or
even introduce a new command? I'd vote for
db_get DOMAIN KEY = get_variables [DOMAIN]
db_set DOMAIN KEY VALUE = set_variable DOMAIN KEY VALUE
since this would correlate nicely to all the other getters and setters
we have so far in the interface. Maybe it would be even better to name
them get_db_variables and set_db_variable to be more precise. What do
you think?
Thomas.
- --
only dead fish swim with the stream: http://thomaskeller.biz/blog
Für Freiheit und gegen staatliche Überwachungsmaßnahmen:
http://leipzig.vorratsdatenspeicherung.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHXTkxaf7NlBYNEJIRAlC9AJ0UAezyEWeOXI1Rt1aZqW1Zv0lOhQCfbhvK
yQgE/j301VlejLiVuEHMmjk=
=gU46
-END PGP SIGNATURE-
#
# old_revision [4c0c4c4111dec5c850e3db5c984c889d1b4d4d95]
#
# patch automate.cc
# from [70e539a80dd102f396e776f1a06760da5606b165]
#to [fce0bfb5651e4b12b02d8efc1050ab0ccffe1981]
#
--- automate.cc 70e539a80dd102f396e776f1a06760da5606b165
+++ automate.cc fce0bfb5651e4b12b02d8efc1050ab0ccffe1981
@@ -1544,10 +1544,7 @@ CMD_AUTOMATE(genkey, N_(KEYID PASSPHRAS
N(!exists, F(key '%s' already exists) % ident);
keypair kp;
- P(F(generating key-pair '%s') % ident);
generate_key_pair(kp, passphrase);
- P(F(storing key-pair '%s' in %s/)
-% ident % app.keys.get_key_dir());
app.keys.put_key_pair(ident, kp);
basic_io::printer prt;
#
# old_revision [4c0c4c4111dec5c850e3db5c984c889d1b4d4d95]
#
# patch key_store.cc
# from [0644bde00d3fd85c7a34eea4cb99f12a4779f40d]
#to [66774adf51e196fd11f574e664bfd9612c0e55de]
#
# patch key_store.hh
# from [9417e9f8b3fc1b2f78424ae80a7a629f23b90ff7]
#to [74aeee95a60ee2cad80456dde2e1cc822d57e378]
#
--- key_store.cc 0644bde00d3fd85c7a34eea4cb99f12a4779f40d
+++ key_store.cc 66774adf51e196fd11f574e664bfd9612c0e55de
@@ -74,6 +74,14 @@ key_store::read_key_dir()
void
key_store::read_key_dir()
{
+ // stop recursion from various places (f.e. keyreader::consume_key_pair)
+ if (reading_keys) return;
+ reading_keys = true;
+
+ // clear the in-memory caches
+ keys.clear();
+ hashes.clear();
+
vectorpath_component key_files, dirs;
if (directory_exists(key_dir))
{
@@ -92,21 +100,14 @@ key_store::read_key_dir()
istringstream is(dat());
read_packets(is, kr, app);
}
-}
-void
-key_store::maybe_read_key_dir()
-{
- if (have_read)
-return;
- have_read = true;
- read_key_dir();
+ reading_keys = false;
}
void
key_store::ensure_in_database(rsa_keypair_id const ident)
{
- maybe_read_key_dir();
+ read_key_dir();
maprsa_keypair_id, keypair::iterator i = keys.find(ident);
// if this object does not have the key, the database had better.
@@ -115,7 +116,7 @@ key_store::ensure_in_database(rsa_keypai
I(app.db.public_key_exists(ident));
return;
}
-
+
if (app.db.put_key(ident, i-second.pub))
L(FL(loaded public key '%s' into db) % ident);
}
@@ -134,7 +135,7 @@ key_store::get_key_ids(globish const p
key_store::get_key_ids(globish const pattern,
vectorrsa_keypair_id priv)
{
- maybe_read_key_dir();
+
Re: [Monotone-devel] conflict messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Scherger schrieb: I'm mostly finished with the cleanup of non-content conflict messages I've been working on lately. Here are some samples from the output of tests/conflict_messages on the net.venge.monotone.cleanup.conflict-messages branch. These mostly follow the suggestions Zack had to my earlier email. Very cool! Just for my understanding... mtn: [left] 312c6ef90e9ed514f28b72b5926fe466c6a9468a mtn: [right] 0442b661dbd5dd18f5ed43b07138bade830bb169 mtn: conflict: duplicate name 'bar' mtn: added as a new file on the left mtn: added as a new file on the right Is this the old multiple nodes want the same parent message? mtn: [left] bc12c73c56eb29876c49e588344920b08e723a44 mtn: [right] fcf6894e6bf1b25299f10470be33fc80c555be6c mtn: conflict: content conflict on file 'foo' mtn: content hash is f1bb6fff2ad16d67143d89fc374ede7abec5d437 on the left mtn: content hash is b966b2d35b99e456cb0c55e4573ef0b1b155b4a9 on the right This is the notice after what the merge dialog usually pops up, right? Its very cool to even see attribute conflicts get properly handled now, thanks a lot for this work! Any plans to merge that in before Richard tags 0.38? Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Für Freiheit und gegen staatliche Überwachungsmaßnahmen: http://leipzig.vorratsdatenspeicherung.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHXUKCaf7NlBYNEJIRAkI4AJ9qf2zWa1+B6OkkdkmYwIwc/z+qSQCgh5E8 +fO/TiZQz3c8nHwWjVRyU0E= =6wrH -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] conflict messages
Thomas Keller wrote: Very cool! Just for my understanding... mtn: [left] 312c6ef90e9ed514f28b72b5926fe466c6a9468a mtn: [right] 0442b661dbd5dd18f5ed43b07138bade830bb169 mtn: conflict: duplicate name 'bar' mtn: added as a new file on the left mtn: added as a new file on the right Is this the old multiple nodes want the same parent message? Indeed it is. Hopefully this is describing the situation a bit more clearly. mtn: [left] bc12c73c56eb29876c49e588344920b08e723a44 mtn: [right] fcf6894e6bf1b25299f10470be33fc80c555be6c mtn: conflict: content conflict on file 'foo' mtn: content hash is f1bb6fff2ad16d67143d89fc374ede7abec5d437 on the left mtn: content hash is b966b2d35b99e456cb0c55e4573ef0b1b155b4a9 on the right This is the notice after what the merge dialog usually pops up, right? Yes. Except that you should now see a message like this for every content conflict that needs resolving *before* the merge dialog pops up. Its very cool to even see attribute conflicts get properly handled now, thanks a lot for this work! Any plans to merge that in before Richard tags 0.38? I think I'd rather wait until after 0.38 actually. It would be good for at least a couple of people to look over the changes in the revisions I mentioned. I really don't expect that this change is going to cause any major problems but a few fetching non-existent entry from children type of errors would not really surprise me. There are a lot of node ids being looked up in several different rosters and while I tried hard to be thorough it's very possible that I've missed something. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] conflict messages
On Mon, Dec 10, 2007 at 09:02:54PM -0700, Derek Scherger wrote: I really don't expect that this change is going to cause any major problems but a few fetching non-existent entry from children type of errors would not really surprise me. There are a lot of node ids being looked up in several different rosters and while I tried hard to be thorough it's very possible that I've missed something. Maybe you could test it? :-) (Depending on what interface it uses, you may just be able to plug it into the giant merge unit tests -- they should be creating every possible conflict situation.) -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
