Re: [Monotone-devel] Time to think about a release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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? ;-) spanish translation fully updated. and sorry for the delay. But I digress... Anyway, it seems like we need to settle the whole mtn:// matter before a release can be done at this point. Also, around last release, there was some talk about merging some branches back into the main branch, but I haven't seen any of that happen... maybe I missed something? Anyway, what's the plan now regarding that? Cheers, Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6u+3mjsZS9ZBxv8RAq6QAJ4sUKWtK1OYaIoin6GqnoxSVIM++wCfeZbo 6Q18eQf+49Q3q72zSRG3Ahk= =2Oip -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Friday 21 March 2008, Markus Schiltknecht wrote: Between 0.39 and now, nvm.experiment.encapsulation has landed, which has been discussed around the time of that release. 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? Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
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 reminder, I will do -right after fixing the schema_migration test... 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. :-) Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Tuesday 25 March 2008, Markus Schiltknecht wrote: 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 reminder, I will do -right after fixing the schema_migration test... 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. :-) How can the changes in nvm.experiment.encapsulation make the database take less space? And why would would you consider changes in the locking behavior a bug? In fact, the current behavior is buggy (imho), because mtn acquires coarse-grained write-locks to the database, so e.g. concurrent access via automate and mtn serve is not possible. And to me it seemed the efforts in nvmee were part of the plan to overcome this issue. Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
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 about nvm.experiment.db-compaction, which hasn't landed, yet. I'm much more into that, at the moment How can the changes in nvm.experiment.encapsulation make the database take less space? Correct, it does not. And why would would you consider changes in the locking behavior a bug? Because its not and intended or wanted change, neither for nvm.e.encapsulation nor for nvm.e.db-compaction. And as such, it might likely be a bug, IMO. In fact, the current behavior is buggy (imho), because mtn acquires coarse-grained write-locks to the database, so e.g. concurrent access via automate and mtn serve is not possible. And to me it seemed the efforts in nvmee were part of the plan to overcome this issue. Yes, a step into that direction. Instead of a database class only, there's now the exposed database interface class, plus a database implementation class, which might be changed underneath and isn't exposed to other parts of the code. Encapsulation. That should flatten the way to a read-only database access (allowing concurrent readers), and maybe even support for other databases. However, it's just one step, we aren't there, yet. (The most difficult thing I see there will be upgrading the read-only database to a writable one on demand). Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Tuesday 25 March 2008, Markus Schiltknecht wrote: Does it make sense to include all those internal changes there? Hm.. probably mentioning it shortly, as I did, does not hurt, does it? What do you think? Imho NEWS isn't solely intended for the end users, but also for the 'devs' who do not following each and every commit, but want to stay up-to-date with the general picture. - Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Tue, Mar 25, 2008 at 9:46 AM, Markus Schiltknecht [EMAIL PROTECTED] wrote: Markus Schiltknecht wrote: Thanks for the reminder, I will do -right after fixing the schema_migration test... I've added something regarding nvm.ee in rev 9caec53c..., Zack, is that paragraph correct? Does it make sense to include all those internal changes there? Hm.. probably mentioning it shortly, as I did, does not hurt, does it? What do you think? I think that's fine. 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. As db-compaction still is in no shape for landing, though, it's kinda moot. (I may have time to hack on it this week. There are still problems with netsync, right?) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
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 those to db-compaction? That branch already contains way too many changes, IMO, so I'd vote for doing that in a separate branch. As db-compaction still is in no shape for landing, though, it's kinda moot. Uh.. are there other problems, besides the schema_migration? (I may have time to hack on it this week. There are still problems with netsync, right?) Nope, I've solved those last weekend. schema_migration is the only failing test remaining (not taking the two failures from mainline into account). Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Tue, Mar 25, 2008 at 10:06 AM, Markus Schiltknecht [EMAIL PROTECTED] wrote: 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 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 changes, and I'm not sure the change I have in mind touches the schema hash. Neither is all that compelling, though. Uh.. are there other problems, besides the schema_migration? I'd like to understand why a regenerate_caches run is necessary, at least. It really oughtn't. Nope, I've solved those last weekend. schema_migration is the only failing test remaining (not taking the two failures from mainline into account). We have test failures on mainline again? ugh. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
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 changes, Oh, yeah, I understand. That's tedious. However, landing db-compaction first would leave only the IDNA change as outstanding :-) and I'm not sure the change I have in mind touches the schema hash. ..while still wanting a schema migration step, that is? Maybe we should add a schema version number or a cuddly name or something, which we can change to force a new database schema hash, without really having to touch the schema. I'd like to understand why a regenerate_caches run is necessary, at least. It really oughtn't. You are right, it shouldn't be needed. I've fixed that now, including an upgrade to the schema_migration test. No regeneration of rosters is needed anymore. (I just forgot to unhex the rosters and roster_deltas checksum). With that fix, db-compaction is successfully running all unit tests, now (with the given exceptions, see below). We have test failures on mainline again? ugh. Unfortunately, yes. Those are: ssh_agent and non_workspace_keydir. The later one being pretty new. But I didn't look into it. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Time to think about a release?
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 before a release can be done at this point. Also, around last release, there was some talk about merging some branches back into the main branch, but I haven't seen any of that happen... maybe I missed something? Anyway, what's the plan now regarding that? Cheers, 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
Re: [Monotone-devel] Time to think about a release?
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 before a release can be done at this point. ATM, two test cases, namely non_workspace_keydir and ssh_agent are constantly failing on both of my machines - which should prevent a release, IMO. Also, around last release, there was some talk about merging some branches back into the main branch, but I haven't seen any of that happen... maybe I missed something? Anyway, what's the plan now regarding that? Between 0.39 and now, nvm.experiment.encapsulation has landed, which has been discussed around the time of that release. I'd like to get current work from nvm.experiment.db-compaction merged, soon. However, I'm not quite there, yet. Some netsync tests are still failing. Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
