Re: [Monotone-devel] nvm.alt_tmpdir
On Mon, May 16, 2011 at 1:23 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Note that 'mv' between two drives succeeds on Windows Wouldn't it be easier to just enhance the POSIX move-this-file function so that it checks if they're on the same filesystem (you can get this from stat(2)), and then either calls rename(2) or does a copy+unlink? -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.alt_tmpdir
On Mon, May 16, 2011 at 2:59 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Stephen Leake stephen_le...@stephe-leake.org writes: Nathaniel Smith n...@pobox.com writes: On Mon, May 16, 2011 at 1:23 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Note that 'mv' between two drives succeeds on Windows Wouldn't it be easier to just enhance the POSIX move-this-file function so that it checks if they're on the same filesystem (you can get this from stat(2)), and then either calls rename(2) or does a copy+unlink? Hmm. Yes, that would be easier. The issue of how to write a test for it is still relevant. One could write reasonable tests of the rename this file, copy this file and then delete the original, and are these two files on the same filesystem? routines (this last is the trickiest, but any linux system will have a separate filesystem stat-able at '/proc', and that already gets you a fair amount of coverage; if there's something similar on OS X and maybe Solaris then that covers most systems of interest). Then the actual move-or-copy routine would be 3 lines of obviously-correct code, so testing it isn't as important. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Roster handling in the code
On Sat, Jul 25, 2009 at 12:39 AM, Patrick Georgipatr...@georgi-clan.de wrote: Yes, but look how it's done. It's in roster_delta.cc, make_roster_delta_t(...): It creates a datastructure containing information about _all_ files in the roster (ie. all 5 in my case), and then loops over them and notes the differences. The cset already contains a list of all changes between the two revisions, so the code could walk a changeset to figure out which roster entries to handle. As most changesets are rather small, that should give a nice speed up. Yeah, that'd probably work -- loop over the cset, convert the paths into node_id's, then just loop over those. The trick is making sure you look up all the correct paths in the correct rosters so you never miss any modified nodes -- this will take some groveling over the exact definitions of the various cset operations and probably some additions to the Giant Roster Tests to make sure the results are the same with/without the optimization. The other way would be to teach the roster+cset - new roster code to keep a list of dirtied nodes, but that might be tricky for merges, I forget. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] deleting erroneous cert
On Tue, Feb 3, 2009 at 7:58 AM, Stephen Leake stephen.a.le...@nasa.gov wrote: We accidently added a bad branch cert to a revision; now it's on two unreleated branches, and there's no way to recover short of editing the database directly to remove the cert. Would 'suspend' help? -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: times to load various things from the database
On Sun, Jan 18, 2009 at 3:14 AM, Thomas Moschny thomas.mosc...@gmx.de wrote: Derek Scherger wrote: - after a reconstruction path is loaded it is scanned in forward order looking for a cached roster to start from. if one is found, the reconstruction path is truncated at that point and reconstruction will start from the closest cached roster. Somehow I always thought the code that searches for the reconstruction patch would do this already: not only stop at base rosters but also at cached rosters - seems I was wrong. Err, yeah, it definitely should be doing that! And if it isn't, it should be fixed to do that, rather than papering it over like Derek described... -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
On Sat, Jan 17, 2009 at 1:47 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Jan 17, 2009 at 6:36 PM, Emile Snyder emile.sny...@gmail.com wrote: There's a link off of the monotone home page. It's channel #monotone on irc.oftc.net I think. Why oftc? Why not freenode? Because it always has been. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] times to load various things from the database
On Sun, Jan 11, 2009 at 8:35 PM, Derek Scherger de...@echologic.com wrote: On Sun, Jan 11, 2009 at 9:04 PM, Nathaniel Smith n...@pobox.com wrote: Right, roster deltas themselves are tiny, and therefore quick to parse (they're basically like revisions). The problem in profiles has always been a combination of poor access patterns/caching, and the overhead of copying the whole large roster structure in-memory before applying the small delta. I don't think disk access patterns are affecting my test as this is on a hot cache and the database fits in ram comfortably. Looking at where database::get_roster_version applies the list of deltas during reconstruction I don't immediately *see* anywhere that is copying the roster, although I'm sure a copy could be hiding in there somewhere. I'm not talking about disk access, I'm talking about the roster cache :-). My impression is that to load N rosters in dag order we end up doing something like: - load roster 1 by loading roster N and applying N-1 deltas to it. - load roster 2 by loading roster N and applying N-2 deltas to it. - ... - load roster N. Which is O(N squared). Yes, if you're doing the O(n^2) pessimal thing, then it will suck no matter what :-). If you reconstruct in the other order, then the cache has a chance to help: - load roster N by loading it from the database - load roster N-1 by pulling roster N from the cache, copying it, and applying 1 delta to it - load roster N-2 by pulling roster N-1 from the cache, copying it, and applying 1 delta to it etc. So for the code you're running the access pattern doesn't play well with the cache, and if the access pattern or cache were better, then the copying would be the big problem, that's what I meant :-). It appears that building the reconstruction_graph to recreate a roster takes time comparable to applying the list of deltas when reconstructing the roster as well and I wonder whether we could do better using the cached revision_ancestry data? The comment in graph.cc about loading too much of the storage graph into memory doesn't seem all that relevant as we load the full ancestry cache in many other places. I doubt it. Profile first, but 1) optimizing inner parts of the algorithm (like delta application or reconstruction_graph building) is useless when the problem is that the outer code is calling them too many times. O(n^2) with one inner chunk twice as fast is still O(n^2), 2) we load the full ancestry cache in very few places these days, we've slowly implemented local algorithms for most things as loading the full graph really does become a bottleneck. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] times to load various things from the database
On Sat, Jan 10, 2009 at 10:58 PM, Derek Scherger de...@echologic.com wrote: However, reading rosters is comparably slow. [...] There is some improvement here but not all that much. It seems that long delta chains are likely a bigger factor. After reconstructing an old roster with a long delta chain (600 deltas), the roster for the next revision is reconstructed by rebuilding essentially the same delta chain (599 deltas) and applying it again. Right, roster deltas themselves are tiny, and therefore quick to parse (they're basically like revisions). The problem in profiles has always been a combination of poor access patterns/caching, and the overhead of copying the whole large roster structure in-memory before applying the small delta. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug in monotone
On Thu, Jan 8, 2009 at 3:02 PM, Thomas Keller m...@thomaskeller.biz wrote: We should try, right. Problem is that the invariant exists at two place (path_component::path_component(string const d) and path_component::path_component(char const * d)) where the original error could either come from the inside (i.e. a roster) or the outside (i.e. the filesystem). To fix this one and for all time we could need something similar like what Timothy recently did with high-level data structures like revision: we'd need some kind of origin parameter. Yell with an invariant if the corrupt data come from the inside, because something broke, give the user a normal error when some external path is wrong. The usual way we've handled this is to have the outside do the checking with a nice error message, and then have the lower-level code just I() on anything it can't handle (but never get called, if the outside caught the problem first). That means when you're looking at the lower level code, you just have to worry about ensuring correctness, and not be distracted by also trying to diagnose the exact source of any incorrectness. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Crash
On Wed, Dec 10, 2008 at 1:33 AM, Markus Wanner [EMAIL PROTECTED] wrote: Ulf Ochsenfahrt wrote: I was just syncing when I got a monotone crash, as you can see from the log below. It's not reproducible - second sync worked. I'm posting it here to preserve the log in case someone encounters this again. No core dump, apparently. I remember having seen this as well, but haven't been able to reproduce it either. A glibc error is rather bizarre, IMO. Might be a good idea to try running some stuff under valgrind; that's the sort of bug it might be able to catch... -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Filesystem normalisation
On Tue, Dec 2, 2008 at 4:16 AM, Stephen Leake [EMAIL PROTECTED] wrote: I'm pessimistic that such a function exists in Windows, but I admit I haven't looked or tested. I'm not sure it exists either, but for the question you raised it doesn't matter -- if it exists we should call it, if it doesn't then there's nothing sensible that a lua hook could do anyway. Enforcing project specific rules is a whole other issue; this is just about interacting correctly with the filesystem... -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Filesystem normalisation
On Sun, Nov 30, 2008 at 8:18 PM, Derek Scherger [EMAIL PROTECTED] wrote: I don't think args_to_paths is the right place to make this change though. That function only deals with paths on the command line and you may just as well get a bad path from a revision committed by someone else on a system that is case sensitive or doesn't have whatever filesystem restrictions that your system does. This isn't about bad paths, just about figuring out which actual path is meant when a user gives us some string. As such, it doesn't actually belong in args_to_paths, but it does belong in file_path_from_external (or whatever the exact name is), which is the code that's actually responsible for taking user-provided strings and turning them into well-formed internal paths. (args_to_paths is just a thin wrapper around it.) There are other issues with filenames that collide on some systems and not on others, but this isn't about that in particular; even if we get better tools for handling such cases, we still want to prevent them from arising accidentally, and that's what this code is supposed to do. (Plus you can't solve the hard problems without the primitive hey OS what path do *you* think this refers to? operation, and so this gets us closer by giving us code to that on at least OS X.) By all means, Peter, send a patch. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn ci failed on NetBSD
On Mon, Dec 1, 2008 at 7:29 PM, Masao Uebayashi [EMAIL PROTECTED] wrote: I got this when I did a first commit in a repository which I've just moved restored. Can you post the full --debug log? -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] weird monotone behavior
On Sat, Nov 15, 2008 at 6:35 PM, Timothy Brownawell [EMAIL PROTECTED] wrote: There's no closing '' on the database line, so really the options file is already invalid. It *should* give an error when trying to parse _MTN/options (and then not overwrite it), and in fact it *does* give an error if I try the same thing with branch x instead of branch 0 . So apparently the basic_io parser can fail to detect certain error conditions... I bet this is the bit where the basic_io code was partly designed for files that mix multiple basic_io formats, and you need to greedily eat all you can of one format and then cleanly return for the next guy in the chain to keep going (think of e.g., extracting a changeset from a revision). So it saw a string /local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn\n branch, followed by an unrecognized token 0, and since that was unrecognized, stopped parsing there. So it thought that the branch was just unspecified, which is legal, and that's what it wrote back out. Guess we need a assert that's the end of the file operation in the basic_io interface. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Lua loading dynamic libraries not possible in monotone?
On Fri, Oct 24, 2008 at 1:28 PM, Zack Weinberg [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 1:19 PM, Markus Wanner [EMAIL PROTECTED] wrote: However, I don't quite understand why it should be a security issue. All hooks are user defined, so what should preventing dynamic loading protect against? Maybe it's rather a simplification for portability? Zack? I honestly don't remember anymore, and I'm not finding any discussion in the mailing list archive. Maybe Nathaniel remembers? No clue; AFAIK this is the first I've heard about it. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] date certs on net.venge.monotone
On Thu, Oct 23, 2008 at 5:12 AM, Markus Wanner [EMAIL PROTECTED] wrote: Thomas Moschny wrote: So, I don't think we should warn there. Even make hints about clock skews. Why is that so unwanted for monotone? Make warns about clock skew (between your local host and its NFS server) because such clock skew breaks Make. Right now, clock skew (between all the hosts used by everyone in a distributed development project) does not break monotone; it continues to provide its basic functionality of managing revisions just fine. Your proposal would compromise this core functionality (either by causing revisions to disappear, or just printing annoying warning messages), so as to better provide the functionality of letting people know that someone else's clock that they can't fix is broken. I understand the impulse, but I don't see how this is the right place for it -- if I really want to know about clock skew, there are better ways to find out, and if don't have access to those better ways, I can just run that script you wrote over my monotone history anyway. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Security
On Thu, Oct 16, 2008 at 9:22 AM, Daniel Carrera [EMAIL PROTECTED] wrote: Reasoning about causality would go a long way: Never trust a revision that is dated earlier than its parent. And it appears to address the specific DOS attacks that Peter found. The date on revisions isn't particularly useful, for all the reasons people have mentioned. Another sort of date is unproblematic and would make recovery from such DOSes easy, though -- add an audit table to each db that records the time (according to the local clock) at which each revision arrived in that db. Most of the time this is just an extra few bytes on the disk, and we don't use it for anything; but if we do wake up one day and discover someone has dumped 10,000 revisions into our server, the it lets us identify those revisions easily -- just revoke that person's access and then throw out all revisions that arrived in the last 24 hours. (It's okay if you throw away some legitimate revisions; they'll get automatically re-pushed by the original committers sooner or later.) -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sat, Oct 11, 2008 at 1:24 PM, Daniel Carrera [EMAIL PROTECTED] wrote: Hello, When you run db kill_rev_locally, does Monotone record who performed that action? E.g. a malicious developer or an unauthorized person who stole a developer's credentials might run this command and we would like to know who it was. No, it simply wipes out the revision and its certs, as if they never existed. (Except that as you note, it does leave some of the associated data behind in the database, but there's no way to get at this data except by poking around in the db by hand.) This isn't really a security issue, though, because it only affects the database that it's run on. If I break into your machine and run kill_rev_locally on some real and important revision, then next time you run 'mtn sync' it will notice that the server has a copy of that revision and your machine does not, and will re-pull it. Nothing is lost. kill_rev_locally only *actually* loses information if the only copy of that information is in the database that the attacker has *direct* access to, and if they have direct access they can remove any record we would like to make anyway. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Please add me to the monotone group on savannah.nongnu.org
On Fri, Oct 10, 2008 at 7:56 AM, Ludovic Brenta [EMAIL PROTECTED] wrote: Someone, please add me to the group so I can at least do basic bug triaging when I have a couple of minutes.. Done. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
On Fri, Oct 10, 2008 at 1:31 PM, Daniel Carrera [EMAIL PROTECTED] wrote: Hello, I'd like to officially request a mtn rebase command. I could try to write it in Lua (I don't know how hard that would be, but I'd try). Usage: mtn rebase revision-id Effect: Edit _MTN/revision to point to revision-id NB that you probably can't implement this in a fully correct way in Lua, because you need to move any pending adds/drops/renames so that they apply to the new base revision; just changing the base_revision field won't do that. If all you have are file edits, then things may be fine; otherwise there's a chance of your workspace becoming inconsistent, and subsequent mtn commands will notice this and refuse to work. It would be quite easy to implement in mtn itself, though, because it has all the high-level code for handling file trees already. Just do something like (untested): revision_id new_base_rid; cached_roster new_base_roster; roster_t workspace_roster; parent_map old_parents, new_parents; temp_node_id_source nis; if (app.opts.revision_selectors.size() != 1) throw usage(execid); complete(app, idx(app.opts.revision_selectors, 0)(), new_base_rid); N(app.db.revision_exists(new_base), F(no such revision '%s') % new_base_rid); app.require_workspace(); app.db.get_roster(new_base_rid, new_base_roster); app.work.get_work_state_shape_only(old_parents, workspace_roster, nis); N(old_parents.size() == 1, F(cannot rebase a merge workspace)); new_parents.insert(std::make_pair(new_base_rid, new_base_roster)); app.work.set_work_state(new_parents, workspace_roster); -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
On Fri, Oct 10, 2008 at 2:30 PM, Daniel Carrera [EMAIL PROTECTED] wrote: Any chance that someone who already knows the sources could implement this feature? It would be a lot easier for you than it is for me. I only began using Monotone on Wednesday. The fact that I already understand as much as I do is a testament to its design and documentation. But still, it's only 2 days. Understood! Unfortunately, I don't have time right now, but maybe someone else will. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
On Thu, Oct 9, 2008 at 5:19 PM, Daniel Carrera [EMAIL PROTECTED] wrote: I don't care much about the database behaviour. What I meant to say earlier is that I'm happy with whatever choice the devs make. I only really care about the workspace (not losing my work). It's worth noting that with 'disapprove', your work isn't lost -- the original commit is still in the database, where you accidentally put it. It can be seen with 'mtn log', 'mtn diff', etc. You also have the option of putting the changes it made into your workspace using the 'mtn pluck' command. Basically, 'mtn pluck -r FROM -r TO' takes whatever differences there are between the revision FROM and the revision TO and applies them to your workspace as edits. 'mtn diff -r FROM -r TO' will show you exactly what changes it will apply. So in this case you could do 'mtn pluck -r THE_ACCIDENTAL_REVISION -r THE_DISAPPROVE_REVISION'. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug report and help
On Sun, Aug 24, 2008 at 11:13 PM, Chifung Fan [EMAIL PROTECTED] wrote: after sync'ing a remove database to my local db, I forgot to do a mtn merge and did a mtn update instead. Then the error popped up. That's fine, you never *have* to merge in monotone. Is the database corrupted? How do I recover the db? The database is fine. mtn update mtn: updating along branch 'com.capok.lbs' mtn: selected update target efdb260f25bd9d208a18410d6d2ba16c2522b052 mtn: [left] 7cc1a9963084affeafb499ecadfe26346c50e156 mtn: [right] efdb260f25bd9d208a18410d6d2ba16c2522b052 mtn: fatal: std::logic_error: paths.cc:411: invariant 'I(utf8_validate(utf8(data)) !has_bad_component_chars(data) data != . data != ..)' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to [EMAIL PROTECTED] mtn: wrote debugging log to /crypt/home/chifung/work/prj/lbs/_MTN/debug mtn: if reporting a bug, please include this file The problem is that there's a path -- probably the name of a file in your workspace -- where monotone is encountering some charset confusion. (Usually, the pathname is in something besides utf8 but monotone is expecting only utf8, or something like that.) If you look at file listed in the output -- /crypt/home/chifung/work/prj/lbs/_MTN/debug -- then somewhere right near the bottom it should tell you the name of the problematic file. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Fwd: [bug #24060] lua error on mtn -add ( invariant 'I(lua_checkstack (st, 1))' violated )
-- Forwarded message -- From: anonymous [EMAIL PROTECTED] Date: Wed, Aug 13, 2008 at 1:33 PM Subject: [bug #24060] lua error on mtn -add ( invariant 'I(lua_checkstack (st, 1))' violated ) To: [EMAIL PROTECTED], [EMAIL PROTECTED] URL: http://savannah.nongnu.org/bugs/?24060 Summary: lua error on mtn -add ( invariant 'I(lua_checkstack (st, 1))' violated ) Project: monotone Submitted by: None Submitted on: Wednesday 08/13/2008 at 20:33 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any mtn version --full: monotone 0.38 (base revision: c1757f6cde49bddd77c82580059105bc470145b2) Running on : Linux 2.6.9-55.QEL4smp #1 SMP Fri May 4 16:08:10 PDT 2007 i686 C++ compiler: GNU C++ version 3.4.5 20051201 (Red Hat 3.4.5-2) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [085f4d04a0bbbc06b44cf6194ca9c2079f924cdd] old_revision [c1757f6cde49bddd77c82580059105bc470145b2] Generated from data cached in the distribution; further changes may have been made. ___ Details: When adding new files in a directory by globbing, we are seeing this: cd /home/dist/files; /usr/bin/mtn --quiet add * 21 mtn: fatal: std::logic_error: lua.cc:282: invariant 'I(lua_checkstack (st, 1))' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to [EMAIL PROTECTED] mtn: wrote debugging log to /home/dist/us/_MTN/debug mtn: if reporting a bug, please include this file We ( clearly ) haven't upgraded mtn in a while, but this was working until just a few days ago. Is there a workaround? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?24060 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Why are untouched files listed on branch merges/propagates?
On Sat, Jul 5, 2008 at 3:39 AM, Ralf S. Engelschall [EMAIL PROTECTED] wrote: But independent what the default is and what the option is named, does anybody already know how to actually implement this filtered information WRT the target branch only? Well, the information sort of exists in the roster -- the marked concept matches what you want exactly, but we also mark file contents when the file was modified on both sides but they merged cleanly at the 3-way merge level. Listing such files might be acceptable, or even desireable. I don't remember whether we have efficient access to roster information from within the log loop. A hack that would be correct in most cases would be to simply list those files which are mentioned in *both* csets (i.e., intersecting the two sets rather than unioning them). (This goes subtly wrong if, for instance, the clean merge would have made side A win, but the user overrode it and made side B win, then there are no changes relative to side B, even though there was user intervention.) -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] case insensitive file names
On Tue, Jun 24, 2008 at 08:43:40AM -0400, Stephen Leake wrote: My actual use case was this: if I have a workspace that is nominally at the head of branch 'main', and I start messing around, then realize I really should be working on branch 'experimental', I want to do: mtn just switch to experimental, and don't bother me! which is approximated by: mtn ls --missing files_i_deleted.log mtn revert --missing mtn update --branch experimental some_painful_shell_script.sh files_i_deleted.log I'd rather just do 'mtn update --branch experimental' :). I'm not sure I follow what you want, but it sounds like mtn drop --missing mtn update -r h:experimental should do it? If you want the files to be gone, why use revert to put them back before updating? -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] case insensitive file names
There's been some blue-sky design scribbling on these issues that you might want to be aware of: http://www.venge.net/mtn-wiki/NonMergeConflicts On Wed, Jun 18, 2008 at 03:46:25AM -0400, Stephen Leake wrote: I just ran into a case insensitive file name problem. I'm on Windows, and I added a file named GDS_Executor.page in a main branch, renamed it to gds_executor.page in another branch, then merged the branches. mtn did not complain during the merge, but it did complain during the update; mtn: misuse: rename target 'gds_executor.page' already exists But then if I delete 'gds_executor.page' from the workspace (but not from mtn), update fails with: mtn: warning: missing file 'GDS_Executor.page' There are a couple of issues here. First, mtn should use a case-insensitive file name compare. More precisely, it should use whatever file name compare the actual file system uses; that may be a case-sensitive NFS on Windows, for example. That would require a standard API for checking file name equality; is there such a thing? Trying to actually create two files and seeing if an error results would work, but probably be too slow. As an approximation, we could lowercase all file names on Windows before doing string equal. That's probably not right if the filenames are actually UTF8 encoded. Is there an appropriate 'lowercase' function? Second, why does 'update' care if some files are missing? They will be restored or not as appropriate by the update anyway. In the current use case, this check just gets in the way. I'll start another thread for that. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mainline unit tests fixed
On Tue, Mar 25, 2008 at 06:27:30PM -0400, Zack Weinberg wrote: On Tue, Mar 25, 2008 at 4:48 PM, Markus Schiltknecht [EMAIL PROTECTED] wrote: 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. Ick. Why are we even looking at $HOME in the testsuite? It's really important that the testsuite not touch *any* of the user's configuration, lest it come to depend on some state in there -- or worse, corrupt the user's setup. (Imagine if at some point in the future we migrate to some other keydir format; we don't want the user testing a trunk build to have their older, system-installed version suddenly stop being able to read their private key!) 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 second one took me more than an hour, because my knowledge of the ssh_agent is pretty uhm.. non-existent. Anyway, it turned out, that removing --ssh-sign=no from safe_mtn() in lua-testsuite.lua did the trick. It looks like Stephen added that in revision d7b34554... I cannot see any reason for that addition, so I've removed it again. I asked for that to be added, for the same reason as above - we don't want the test suite touching the user's ssh agent any more than their .monotone directory. Most of the tests do not have anything to do with the ssh agent and should not use it at all, hence --ssh-sign=no in safe_mtn(). The ssh_agent test case (and all other hypothetical tests that do need the agent) ought to spawn a private copy of the daemon and kill it when it's done. The problem isn't spawning a private copy of the daemon, IIRC the tests do that; the problem is that after spawning a private copy of the daemon, we need a way to run the mtn binary that will actually be willing to talk to the daemon :-). That's part of why we have all the different *mtn() functions, because different parts of the test suite can accept more or less defaults. Maybe in this case the right solution is to add an extra --ssh-sign=yes to the agent tests, though -- will that override an -ssh-sign=no given earlier on the command line? -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
On Fri, Mar 21, 2008 at 06:34:33AM -0500, Timothy Brownawell wrote: 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 path, so it'll work with file:// and ssh:// sync). There's one strong argument for sticking with standard URL syntax: the quoting issues are already solved. In particular, with the include= style there is a standard, obvious way to include branches that have characters like in them. It's not a *pretty* way, exactly, but existing deployment can beat purity. Also in an ideal world, people wouldn't have reason to keep using funky include/exclude patterns, so they would just set a string once (when they first pull) and then never touch it again, and so shell quoting issues wouldn't matter. But we're not in the world, so eh. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] IPv6 addresses and ports (and netxx)
On Wed, Mar 05, 2008 at 08:19:31AM +0100, Lapo Luchini wrote: Which leads me to the following question: is upstream netxx still alive? The answer is no. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Summer of Code 2008
On Tue, Mar 04, 2008 at 06:13:45PM +0100, Thomas Keller wrote: Thomas Keller schrieb: I've just read on Slashdot that Google announced the fourth edition of its Summer of Code [0]. We certainly want to participate this year, don't we?! They start accepting applications from mentoring organizations from March 3rd - I'd like to team up with somebody who has some more experience with the program than me and bring it foward. Anyone up to help out? So, the application is now open and I've started to collect information for our very own application in the wiki [0]. Could one of the guys who're sending the application last year / the year before last year give me the original application texts as blueprint for this year's application? 2006 was disorganized enough that there wasn't really any formal application. The application for 2007 (that they ended up not reading because of confusing deadline issues) is still up at http://www.venge.net/mtn-wiki/SummerOfCode2007 and probably most of it still applies. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Summer of Code 2008
and disappeared. Even more unfortunately, it was a project outside our normal area (writing an Eclipse plugin), so we had no backup mentor available. I eventually had to teach myself Java and Eclipse so that I could give him guidance and set milestones; but it turned out that even though he wrote a really excellent application, he was simply quite clueless about coding, and could not accomplish even the simple tasks he attempted. This year we only listed projects that have backup mentors, and have tried to make our application process more informative for us. 4. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? N/A 5. Who will your organization administrator be? Please include Google Account information. Nathaniel Smith, [EMAIL PROTECTED] 6. What license does your project use? GPL v2+ 7. What is the URL for your ideas page? http://venge.net/monotone/wiki/SummerOfCode2007 8. What is the main development mailing list for your organization? monotone-devel@nongnu.org 9. What is the main IRC channel for your organization? #monotone on irc.OFTC.net 0. Does your organization have an application template you would like to see students use? If so, please provide it now. Yes (also included on the ideas page): --- begin proposed application template --- (If you have any questions about this application form, you can try #monotone on irc.oftc.net via IRC or monotone-devel@nongnu.org via email for general questions, and [EMAIL PROTECTED] for private questions.) BACKGROUND: Who are you, beyond some characters on a screen? Tell us a little about yourself. Why are you applying to SoC? What do you hope to get out of it? Why are you applying to monotone, instead of some other project? What about it appeals to you? We would very much like to read some code, even if it just for a school project or whatever. Please give a URL for some code you have written in the past (alternatively, email a .zip or .tar.gz file to [EMAIL PROTECTED], and note here that you have done so): Have you talked to us already, for instance on IRC or the mailing list? If so, what nick/email did you use? (This is to help us match up the people we remember talking to with the apps on Google's site.) LOGISTICS: What is your work schedule this summer? In particular, when do you anticipate starting work, will you be gone for any time during the summer, and roughly how much time do you anticipate spending on Summer of Code work each week? How can we contact you if we have questions about your application? Please include any or all of IRC nicks, email addresses, IM screennames, phone numbers, whatever you feel comfortable giving us (we will not make them public) and will allow us to reach you. We know that there is a lot of writing on our Summer of Code page at http://venge.net/monotone/wiki/SummerOfCode2007 , but we wouldn't have written it all if we didn't think it was important. To show us that you've read that page, what is the magic word that is mentioned in parentheses at one point in the text? PLANS: Please list the projects you plan to work on this summer, if accepted. At a minimum, this list should include what the projects are, how long you anticipate each will take, a breakdown of where that time will go, and what results you will achieve at each stage: Please list some places where the schedule you just gave could run into problems. Which do you think are the most likely, and what will you do to adjust if they do occur? Final question: Why should we choose you to receive money for doing the above work, rather than some other student? --- end proposed application template --- 11. Who will be your backup organization administrator? Please include Google Account information. Matthew Gregan, [EMAIL PROTECTED] 12. Who will your mentors be? Please include Google Account Information. Nathaniel Smith -- [EMAIL PROTECTED] Matthew Gregan -- [EMAIL PROTECTED] Matthew Johnston -- [EMAIL PROTECTED] Jack Lloyd -- [EMAIL PROTECTED] Thomas Keller -- [EMAIL PROTECTED] and likely a few others as well that didn't get their google account info to me in time. 13. What criteria did you use to select these individuals as mentors? Please be as specific as possible. Being a small project, there wasn't much formal process involved -- they are all people who are already in our community, I know can be trusted, and they expressed interest in participating. 14. What is your plan for dealing with disappearing students? There isn't all that much that can be done with a disappearing student -- we will try to contact them, but... Talking to Leslie last month, she suggested that this year it will be possible to drop students before the first payment, if they are not showing signs of existence. I haven't seen this confirmed or elaborated on the SoC site, but assuming it is true: this seems like an excellent idea to us; and it fits into our Crazy Scheme
Re: [Monotone-devel] dir containing db.mtn as uri
On Wed, Feb 13, 2008 at 05:28:46PM -0800, Roland McGrath wrote: The journal files and such mean that for separating each project into its own db with user file permissions controlling access by accounts on the same ssh server, each db really has to live in its own directory with the right project's permission settings. So I can't just use /mtn/project as the name of the db file itself. Makes sense to me, but we'd need a patch for the manual so this doesn't just remain a secret easter egg, and a test so it doesn't get taken out (accidentally or otherwise) in some later version. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release recommendations?
On Wed, Feb 06, 2008 at 11:41:36AM +0100, Richard Levitte wrote: I'm thinking of making a release pretty soon, but I'm wondering if there's any opinion on what should be included. There are a few interesting development efforts going on, such as encapsulation and policy-branches, and the question is if we should wait for them to become part of the main branch or not. My opinion is that every time we catch ourselves thinking release and wait for ___ in close proximity, we should smack ourselves and go back to making the release. Remember the pathological spirals *every* FOSS project used to get into back in the day, never releasing...? -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Tue, Jan 29, 2008 at 10:41:21AM +0100, Patrick Georgi wrote: There might be some GNU/GPL rewrite of it - at least something along that lines was planned. But given that other libssl-using GPL sources aren't build against such a replacement in the Debian repository (eg. netatalk), I might be mistaken on it (or that project just isn't far enough yet) You're thinking of GnuTLS, which AFAIK is mature. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
On Tue, Jan 29, 2008 at 12:40:56PM +0100, Markus Schiltknecht wrote: Yeah, and that argument gets even stronger if you take imports or pulling from foreign VCSes into account: you will have to pull in commits, tags and branches, and certainly can't recycle the cert from the source VCS (if here even is such a thing). Having distinct signer and authors for tags and branches makes sense in those cases, IMO. Deferring that complexity to commit messages, which then have to be parsed by third party tools strikes me as a rather bad idea, taking flexibility from monotone. If you need clean roundtripping, author fields are hardly your worst problem. You're going to need to add extra system-specific metadata regardless, and hey, look at these nice user-extensible cert things... :-). -- Nathaniel -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
On Mon, Jan 28, 2008 at 08:51:03PM -0700, Derek Scherger wrote: Thomas Keller wrote: Does it really make sense to have an author field for anything beside a commit cert? If you tag or test something, you do not become the author of anything, you just mark something somehow. When I look at the proposed database table schemes so far I somehow have the impression that we rather have a hard time of applying the same metadata which fit perfectly for non-commit certs on commit certificates - i.e. tag, branch, suspend and testresult perfectly fit into the (name,value,comment?,date,signer,signature) tuple scheme, just commit certs do not because they can optionally have an author which is different from the signer. One reason for separating out the author from the signer is that, in the event of a database rebuild, all certs will be re-signed by whoever does the rebuild and the original author is lost. This has happened a few times in the monotone history and while not a huge problem does leave rebuild a little more lossy than it could be. My current feeling is that separating out signer from author is a bad idea. The cost of having them is paid all the time -- you have two different identities to worry about every time you print a log message, there are security concerns (people who are confused about identity can cause a mess), etc. The cost of not having them is this annoyance with database rebuilds, which are *very* rare, and for them ad hoc techniques suffice. (For instance: just munge a note about the original author into the commit message programmatically.) -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Is the windows port active?
On Sun, Jan 27, 2008 at 05:58:41AM +, Nuno Lucas wrote: One is monotone complaining about file names which are not Unicode (there was file name corruption because the original source code was compressed with a non-Unicode zip application). I believe this to be a bug on monotone, because it's not it's job to assume file names are Unicode. It should behave like the linux and windows kernel, where file names are treated like blob's (with a few restrictions). Unfortunately, that is wrong, because mtn is a tool for collaboration, and different people have different locale configurations, and thus need to use different binary blobs to get the same filename. If you add a filename using some ISO8859 charset, and then I check it out in my utf8 locale, I'll get nonsense. So monotone needs to know how to convert between its internal (utf8) representation and that of the user's local filesystem. What you ran into is a really long-standing bug where mtn's directory scanner (invoked only for 'ls unknown', recursive add, and a few other things) doesn't properly do character conversion. This is true on both win32 and posix, just you probably are using a utf8 locale on linux, in which case the missing conversion is a no-op anyway, so you haven't had a problem. This would certainly be a good bug to fix, it *keeps* biting people. And just now (the reason I decided to write this), because monotone opened Notepad to let me enter the commit message and bugging out because it couldn't convert my message to UTF-8 (the message was written in plain Portuguese, nothing extraordinary). Oh, and it failed to preserve the bad message in _MTN/log Dunno why that would be -- presumably either some sort of bug in guessing what charset you used, or (less likely) a bug in monotone's charset conversion routines on win32. Monotone seems to think that you wrote your commit message in Portuguese_Portugal.1252, and that's what it tried to convert out of -- what charset does notepad spit out for you? -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branches
On Fri, Jan 11, 2008 at 12:01:37PM +1100, Brian May wrote: Hello Can I please check my understanding? I have the following tree: A1 |\ | \ | \ A2 B2 | | A3 B3 | A4 | A5 At this stage, I realize that the B changes are going to require more work then I initially anticipated. I would like to move B into a separate branch. I think this is easy, just add another branch certificate to B2 and B3. However, won't monotone still see two heads in the original branch? Yes. If so, what is the correct way to proceed? The best approach is probably a double-revert. First, revert the changes in the mainline branch: $ mtn co -r B3 $ mtn pluck -r B3 -r A1 # note that these are listed backwards $ mtn ci -b mainline # should be default, but just to be clear Now we have: A1 |\ | \ | \ A2 B2 | | A3 B3 | | A4 B4 (= A1) | A5 Then, reapply them into the new branch: $ mtn co -r B4 # or just use the same workspace from above $ mtn pluck -r A1 -r B3 # note that these are listed forwards now $ mtn ci -b newbranch A1 |\ | \ | \ A2 B2 | | A3 B3 | | A4 B4 (= A1) | \ A5 B5 (= B3) This approach is a little more cumbersome than just issuing certs, but it means that future merging will all work as expected -- in particular, mainline still has two heads (A5 and B4), but when you merge them then A5 will win. Also, merging from mainline into your branch will work as expected, and eventually you will be able to merge from you branch into mainline, and that will also work as expected. (The main alternative would be to revert the B stuff on mainline, but then just use B3 as the start of your branch -- if you did this, then the first time you merged mainline and your branch, the merger would happily say that the new reversion in B4 won over the changes in B3 and clobber your work.) Cheers, -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Directory already exists?
On Mon, Dec 17, 2007 at 06:15:11PM +1100, Brian May wrote: Timothy == Timothy Brownawell [EMAIL PROTECTED] writes: if a directory already exists, so what? presume it was already added by a incomplete update and continue Timothy We currently think of directories as objects, so stomping Timothy on an existing directory is just as bad as stomping on an Timothy existing file. I consider this a good thing. If I manually created a directory and it conflicts with an update, chances are I didn't realize that the directory name was already in use. I don't want monotone to assume that the purpose of the new directory is compatible with the directory in the repository, as this may not be the case. Well, trashing the workspace is never a good thing, no matter how noble the intentions :-). Could we just handle this case by issuing a warning and continuing anyway? Seriously, it would be like 3 lines of code and definitively better than what we have now... -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I can haz mtn:// plz?
On Tue, Dec 11, 2007 at 02:07:40AM -0800, Zack Weinberg wrote: An it-would-be-nice: if mtn pull/push/sync mtn://server/branchpattern fired up the netsync protocol. if only so one could get a bit of mileage out of Vcs-Mtn: in Debian package control files, which are currently only good for ssh transport. I think. +1 -- Nathaniel ___ 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
[Monotone-devel] Fw: [bug #21706] automate packet IO broken on 0.37
So people don't miss this... -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ---BeginMessage--- URL: http://savannah.nongnu.org/bugs/?21706 Summary: automate packet IO broken on 0.37 Project: monotone Submitted by: zzagorski Submitted on: Monday 12/03/2007 at 07:49 Category: networking Severity: 3 - Normal Item Group: incorrect behavior Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any mtn version --full: monotone 0.37 (base revision: c21eefc002b8f9c430e9f4cc16c4af7b852f54ec) Running on : Linux 2.6.12-co-0.7.1 #1 Sun Dec 31 20:25:16 UTC 2006 i686 C++ compiler: GNU C++ version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) C++ standard library: GNU libstdc++ version 20071123 Boost version : 1_34_1 Changes since base revision: format_version 1 new_manifest [e5347a0b2e7d2dfa98bb7dd822fea387193b2a31] old_revision [c21eefc002b8f9c430e9f4cc16c4af7b852f54ec] Generated from data cached in the distribution; further changes may have been made. ___ Details: $ mtn automate packet_for_rdata 73523223ab76d83954f6284243c69a5b3726b91d | mtn read mtn: warning: unknown packet type: 'rdata' mtn: misuse: no packets found on stdin Namely: monotone (0.37) is unable to read rdata packets that is produces. 0.36 can read rdata packets it produces. 0.36 can read rdata packets produced by 0.37. Aha, 0.36 and 0.37 generates identical packets for same revisions so looks like only read is broken. Don't see problems with fdata and fdelta packets. Tested on: win32 (mingw) and linux(linux x86/glibc 2.4). ___ Reply to this item at: http://savannah.nongnu.org/bugs/?21706 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ---End Message--- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] hang on Win32/MinGW with sync file:
On Mon, Dec 03, 2007 at 07:04:28PM -0500, Stephen Leake wrote: Although I think using sockets would open up a security hole; file: runs the server with --no-transport-auth. So for a brief time an external machine could attach to the server. Surely win32 sockets can be bound to loopback, so only local processes can connect? That doesn't *fully* close the hole, but it helps. What would fully close the hole would be to generate a random nonce, and send it over the socket as the first thing we do -- since we hold both ends of the socket, we know what random nonce to expect, but no-one else would. This could be fully hidden within the socketpair code (i.e., it would transmit and receive the nonce to check the connection before returning the sockets). -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] hang on Win32/MinGW with sync file:
On Tue, Dec 04, 2007 at 01:48:57PM +1300, Matthew Gregan wrote: I don't think so. The listener is bound to localhost and expects exactly one connection. The port number is ephemeral. The other end of the socket is set up immediately. Worst case, an attacker can guess the ephemeral port number and connect to it, but it will just cause socketpair() to return an error because its own attempt to connect to the listening socket will fail. Oh yeah, that works too... -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: MtnSummit 2008
On Mon, Nov 19, 2007 at 10:22:03PM +0100, Lapo Luchini wrote: Thomas Keller wrote: Stand up, speak up! Zurich vs Wuppertal: shall we need to toss the proverbial coin? ;-) Both seem interesting and have their pros, and no one seems like really standing up for one or the other... but this way time flies and we risk more and more likely to choose neither, which would be a real pity ;-) Well, OK. One difference is that Siggi has apparently gone ahead and down a huge pile of work for Wuppertal: http://article.gmane.org/gmane.comp.version-control.monotone.devel/13143 and no-on has done squat for Zurich (AFAICT, I might well have missed something). I guess it's true that no-one is standing up and saying this is what's happening, which is usually the only way to get this kind of crowd all moving in the same direction. I can see how Siggi would be uncomfortable with just dictating to the list like that, though. I dunno, would it help if I just made some dictatorial pronouncement? Hereby let it be known that as far as I can tell, Wuppertal is kicking Zurich's butt this time around, so if we want this to happen we should all line up to make it happen in Wuppertal, or come up with some good reason why not. (I guess dictatorial pronouncements traditionally do more than just make factual observations about the world, but hey, if it works...) -- Nathaniel -- The best book on programming is still Strunk and White. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Patch] Add a '--by' option to 'mtn log'
On Sun, Nov 18, 2007 at 09:08:12PM -0700, Derek Scherger wrote: Nathaniel Smith wrote: It would also be nice to be able to log only revisions from a particular branch (i.e. the one you're working on) sometimes. That's the nice thing about restrict: mtn log --restrict b:foo It multiplies the power of selectors. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] MtnSummit 2008
On Mon, Nov 19, 2007 at 09:22:43AM +0100, Siegfried Herbold wrote: I've done some organisation for location Wuppertal, but I don't want to do more if it is not clear which location we choose: solved problems: - free accomodation for min. 10 people - all cables, switches, ... - free internet - free room, but no date fixed - local transport - food (I hope 80� for hole week) Wow! open tasks: - international travel (I can't search for more funding) - date We have some amount of money still (stored in a highly professional place, i.e., my bank account). I can dig out the numbers on how much at some point. It's somewhere in the 0-2000 USD range, IIRC. (With the way USD is going these days, that probably comes to like 2 cups of coffee and a sausage, of course.) I don't have any special insight on where to find additional funds. If anyone knows someone who knows someone or has a clever idea or anything like that, speak up, I guess... @njs: something important forgotten? Accommodation/transport/workspace/lodging are definitely the Big Ones, and I'm not thinking of anything else critical right now. If I do then I'll let you know. -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Patch] Add a '--by' option to 'mtn log'
On Sat, Nov 17, 2007 at 11:35:30AM +, Matthew Sackman wrote: Sorry, what's wrong with mtn log --from a:[EMAIL PROTECTED] ? mtn log --from a:[EMAIL PROTECTED]/b:the.branch.i.want --last 1 seems to work pretty well for me. I think we've mentioned having a --restrict option or something like that that would be somewhat nicer than the --from hack: mtn log --from h:somebranch --restrict a:someone for instance. (In a perfect world, it could even do smart graph reduction.) -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] MtnSummit 2008
On Sat, Nov 17, 2007 at 01:05:39PM +0100, Markus Schiltknecht wrote: so, we're actually looking for a volunteer who is able to spend some time on more serious planning and organization. I'm willing to support him/her as much as my current schedule allows it, but I won't have the time to do it on my own. Stand up, speak up! I've offered that for Zurich about a month ago. But I got the impression that it's too expensive for most people. Additionally, I'm somewhat disappointed by the low interest. But that might rather be an issue of my expectations :-) I'd suggest lowering your expectations :-). When I started planning last year, I figured there were about 3 people I was pretty sure would come, and then maybe a few more would show up, but hey, I wanted to meet those people and it would still be fun, so I went ahead. Then I got blown away when there were like 20 of us! Maybe there won't be 20, who knows with money, different people are more or less busy now, a place that's more or less easy to get to for different people -- but would it be worthwhile if there were only 5? If so, go for it, plan on that, and then whatever happens will be great... Also, in general, if you (for any value of you) are waiting for a crowd to come and push you to make things happen, it doesn't really work that way... the organizer's job is to push the crowd around, not vice-versa :-). Which is annoying, but sometimes if you want something to happen you just have to decide to commit a bunch of time and hope; otherwise definitely nothing will happen. /sage-old-advice -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Can't merge in Monotone on WinXP
On Sun, Nov 11, 2007 at 02:26:46PM -0500, Benjamin Place wrote: Can you help me? Does it require Cygwin? I've look through the monontone-devel mailing list archives, but everything I saw there was for Cygwin. You shouldn't need cygwin, no. Windows XP Pro SP2, no cygwin. I've set %MTN_MERGE% to C:\Program Files\TortoiseSVN\bin\TortoiseMerge.exe, C:\Program Files\TortoiseSVN\bin, C:\Kdiff3, C:\Kdiff3\kdiff3.exe with no better results. MTN_MERGE is not the path to the merge program -- just knowing the path to the merge program is useless to mtn, because every merge program needs to be invoked in a different way. MTN_MERGE is just a magic key into mtn's internal table of mergers; you should set it to tortoise or kdiff3, and that will invoke the code that knows how to run TortoiseMerge.exe or kdiff3.exe, respectively. (However, the executables do need to be findable on your path, then.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] How to apply automate get_revision data
On Sun, Nov 11, 2007 at 11:39:55AM -0600, Brian Downing wrote: I was wondering if there is a reliable way to apply the data from automate get_revision to transform one revision to the next. I'm toying with a monotone to git converter, which is pretty simple, but automate get_manifest_of is painfully, painfully slow. (Around 3/4 second for the OpenEmbedded repository on my machine.) You might want to try using 'automate stdio'; if you do get_manifest_of through automate stdio, then the successive invocations can share caches. Depending on what order you're fetching the manifests in, this may turn an O(n) operation into an O(1) one (where n is history size -- delta reconstruction has to walk the history graph). automate get_revision is pretty fast, but consider this example from the monotone repo: [...] I have no idea what order to apply that information to get something sane. Certainly renaming a file (to itself?) after deleting the directory it lives in makes no sense to me. Trying a simple 1:1 mapping to git-fast-import seems doomed to fail, as the first delete win32 blows the whole thing away, including win32/read_password.c. In general, there is no order you can apply them in; they are to be applied all at once. It's more like a declarative description of how two trees map to each other than it is a procedural description of how to produce one tree from another. The algorithm for working with such things is a little subtle; the best description I know of is: http://mebentley.blogspot.com/2005/12/tree-transforms-on-posix-filesystems.html (This is Aaron Bentley talking about bzr, but mtn and bzr independently invented identical algorithms here, so it still applies.) -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] more on commit without -b option
On Sun, Nov 11, 2007 at 09:13:14PM -0800, Zack Weinberg wrote: As someone who habitually edits _MTN/options to get this effect, may I add that it would be really nice if this sequence # workspace is on branch foo.bar, but not at its head $ mtn branch foo.bar.newbranch $ mtn update brought the workspace to the head of foo.bar, without changing the selection of foo.bar.newbranch for a subsequent commit. (This is *not* what happens now; you get an error message, have to say -rh:foo.bar, and then you lose the .newbranch selection. To make this more motivated, consider setting .newbranch, going away for a few days, and then wanting to update to the latest baseline before you start hacking.) I sympathize with the use case. Before we implement it, can you propose a few-sentence description for the manual that will make this behavior clear to the meanest intelligence? Alternatively, it occurs to me that in the presence of workspace-merge, merge -r h:parent-branch can probably accomplish what you want. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] error in mtn merge hook
On Fri, Nov 09, 2007 at 05:24:16PM -0500, Faré wrote: mtn: warning: [string std hooks]:796: bad argument #2 to 'format' (string expected, got nil) mtn: error: merge failed due to unresolved conflicts Yes, this is a stupid bug in the message formatting code in the merge hooks... fixed on mainline. Workaround is to set a merger explicitly rather than let monotone pick one, either by adding merger = foo to your monotonerc, or by setting the environment variable MTN_MERGE=foo. Values for foo: meld, tortoise, vim, rcsmerge, diffutils, emacs, xxdiff, kdiff3, opendiff -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn automate way to get file list withoutworkspace?
On Wed, Nov 07, 2007 at 08:02:38AM -0600, Kelly F. Hickel wrote: Ahh, the error below is what confused me, I thought it meant that I needed a workspace, but I just needed to provide a branch [EMAIL PROTECTED] mtn_convert]$ mtn -d eadev.mtn automate get_manifest_of mtn: misuse: workspace required but not found Ah, right, 'get_manifest_of' with no argument is assumed to be asking for the manifest of the current workspace. (What revision were you expecting to get the file list of without giving any argument?) The normal use would be to give a revision. (Not a branch, though the revision could be the head of a branch. Which you can write like h:branchname, except most automate commands don't take selectors, if you want selector expansion you can request it with 'mtn automate select' and then pass the output to get_manifest_of.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn automate way to get file list without workspace?
On Tue, Nov 06, 2007 at 08:20:09PM -0600, Kelly F. Hickel wrote: So, I've started whacking together a mtn/viewvc mashup, but didn't get too far before I realized that a number of the mtn commands I need seem to need a workspace to function. Am I going to have to cobble up a shadow workspace directory just to do this, or is there a semi-reasonable way to get file lists and so forth without one? Very few automate commands involve a workspace... what do you mean by file list? Getting a list of unknown or ignored files requires a workspace, obviously; for getting a list of files in a revision, see automate get_manifest_of. -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Key identities...
On Sun, Nov 04, 2007 at 07:55:10PM -0600, Timothy Brownawell wrote: Could we also handle this by making process_data_command error() on data_exists for a key item? I believe all keys are sent before any certs are sent, so this should block any key collision errors from propagating over netsync. It already does error out if you try to put two keys with the same name into the same db. I'm not quite sure how the developer in question managed to achieve this -- maybe Ethan will explain in more detail. It sounds like he once upon a time generated a key, issued some certs, and then erased that key and used another key for all actual work -- and now, much later, somehow managed to accidentally release one of those old certs into the wild. I don't know if the db that the bad cert came from even contained the offending key or not. Does netsync really send keys first before certs? I don't remember that. (In general we don't consider it an error to have a cert without a key, so it might not be being handled the same way as say files-before-revs-before-certs.) Does netsync send certs that it doesn't have a key for? Those should probably just be ignored, but perhaps they aren't... (For that matter, is there any reason to ever send along a cert with a broken signature? Of course, we don't cache signature checks in the db ATM and checking cert signatures is expensive, sigh.) -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Key identities...
On Sun, Nov 04, 2007 at 07:13:08PM +0100, Richard Levitte wrote: So, I'm wondering, is there any reason, except for the database migration that will follow and the fact that *someone* will have to do the job, that stops us from switching to identifying keys by fingerprint rather than name, at least internally? Define identify? It is certainly a security problem to allow a user to end up with multiple keys that are indistinguishable in normal use, because they are always described the same way (by printing the key name). (Running 'ls keys' and squinting at the output does not count as distinguishable in normal use.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Stange Behaviour In Version 0.37
On Sun, Nov 04, 2007 at 06:10:59PM +0100, Lapo Luchini wrote: 3) Because of I suspect point 2 `mtn update -r h: -b net.venge.monotone.types' from branch net.venge.monotone also fails where it used to work for 0.35. I'm not quite sure you can first use heads (from the current branch, I'd suppose) and *then* change branch... but never tried that, so I'll leave the answer to more knowledgeable people ;-) mtn's command line options never care what order they're given in. (Well, maybe there are cases where two options conflict, like --dump=foo --dump=bar where the second takes precedence.) -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: zlib vs gzip
On Wed, Oct 31, 2007 at 11:30:08AM -0400, Jack Lloyd wrote: On Wed, Oct 31, 2007 at 08:00:11AM -0700, Zack Weinberg wrote: I'd like to point out that the #1 easiest thing anyone could do right now to speed up monotone is get hand-optimized assembly SHA1 implementations into our copy of botan. That one function shows up as at least 7% of runtime every single time I profile it, doesn't matter what the task is. Oh: and how can one go about properly profiling monotone? See also the branch net.venge.monotone.contrib.benchmark, which has a little benchmark harness with pieces for running various commands under different profilers, some stuff for generating synthetic test DBs (though IIRC the DBs generated are not very realistic ATM because they contain no merges), etc. It certainly doesn't do everything, but it can be some pretty handy things as is, and is easy to extend. (The idea is that it isn't any harder to add a new test to this than to write an ad-hoc test script, and then you get a lot more flexibility and reusability.) -- Nathaniel -- The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [Monotone-commits-diffs] Revision 33eb2173fe9b55da6b26464380c68b8c02638a68
On Wed, Oct 31, 2007 at 05:04:15PM +0100, Ralf S. Engelschall wrote: On Wed, Oct 31, 2007, [EMAIL PROTECTED] wrote: * cmd_diff_log.cc (print_indented_set): Replace the empty string printed for the project root with a single dot. * tests/merge_into_workspace: Fix test accordingly. Thanks. Can you also apply something similar to the output of mtn stat? There one has a similar nice output like attr on \n instead of attr on . It's more confusing on stat, since stat can be called from subdirectories of the root... of course, it always gives paths relative to the root anyway, so at least it would still be consistent. My suggestion for this has been to have a uniform function for formatting paths for user display (in log, stat, etc.), that would look like: file_path(foo) - 'foo' file_path(foo bar) - 'foo bar' file_path() - '' (the root directory) (The uniform function part is probably more important than the exact output, because the output is easy to tweak once it's been centralized to one point in the code.) -- Nathaniel -- But suppose I am not willing to claim that. For in fact pianos are heavy, and very few persons can carry a piano all by themselves. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: 0.37 dumps on my FreeBSD-6-stable amd64
On Mon, Oct 29, 2007 at 10:33:41AM +0100, Lapo Luchini wrote:
177 shared_ptr operator=(shared_ptr const r) // never throws
178 {
179 px = r.px;
180 pn = r.pn; // shared_count::op= doesn't throw
181 return *this;
182 }
...and I have no clue how a variable assignement could dump a program,
and only with -O2 with that regard.
Variable assignment can dump a program in this case, given that the
value being assigned is r.px, and r is a reference, therefore
evaluated r.px involves a pointer dereference.
I'm not sure how one acquires a null reference to a shared_ptr,
though. Possibly something else is going wrong. (Have you
valgrind'ed?)
-- Nathaniel
--
If you can explain how you do something, then you're very very bad at it.
-- John Hopfield
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 0.37 released
On Fri, Oct 26, 2007 at 10:12:33AM +0200, Markus Schiltknecht wrote: Argh... looks like we were using an old gzip.cpp, which does no longer exist in botan. I've removed that and pulled in zlib.cpp, from botan's comp_zlib module, which seems to be the proper replacement. Unfortunately some tests are still failing. I'm working on it... Did it ever exist in botan, or was gzip.cpp something that Matt added to our local copy to make our switch easier? -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] zlib vs gzip
On Fri, Oct 26, 2007 at 09:28:34PM +0200, Markus Schiltknecht wrote: Hi, Markus Schiltknecht wrote: Aha.. yeah, that would explain the incompatibility between the two. Thanks for the hint. Okay, in the meantime, I figured that gzip and zlib really are two different encapsulation formats (for the same type of compression algorithm, though). Matt's [1] mail explains that quite well. Looks like zlib ( 1.2) supports both, but botan only supports zlib style headers and footers. We could (and probably should) use zlib only, instead of gzip, but that would cost a netsync flag day. Or maybe we could flutter our eyelashes at Jack Lloyd and get gzip support upstream into Botan, like I guess we should have a while ago just this doesn't come up very often? Jack? I'd still like it best, if we could get rid of gzip.cpp, to get closer to compatibility with the default botan distribution. Otherwise maintenance work will grow infinitely. Well. As I've cold-heartedly deleted the gzip files Matt created from the n.v.m.botan branch, I fear I've killed history for those files. I've now readded those files in the monotone main directory, because I'm under the impression that it's our code, which we have to maintain. Even if it's botan derived, I don't think that code belongs to the botan directory. And having it there will prevent similar mistakes like mine this morning. Sorry for the trouble. For some reason the update to botan 1.7.2 caused a unit test to fail (transform_corruption_check). That was the main reason for me to look into that whole issue at all. Anyway, I've now fixed that in the newly added gzip.cc, so we are at botan 1.7.2, and at least on my box, all tests are fine. Regards Markus [1]: Matt: comments on .sqlite3.binary branch http://thread.gmane.org/gmane.comp.version-control.monotone.devel/5755/focus=5783 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Accept mtn di as mtn diff
On Wed, Oct 24, 2007 at 10:52:27AM +0200, Julio M. Merino Vidal wrote: I do not think this change is appropriate. monotone already allows shortened names of commands It also already has a number of built-in aliases of this type. (Note he didn't have to add any code...) , and in fact 'mtn di' would work if it didn't found multiple completions: $ mtn di mtn: misuse: 'di' is ambiguous; possible completions are: mtn: misuse: informative diff mtn: misuse: review disapprove $ Yes. Such completions are non-discoverable (how the heck do I know what the shortest unique prefix of a command is? I would need like half an hour and scratch paper to work this out); they create weird long-distance coupling in the UI since shortcuts can be changed by the addition or removal of entirely unrelated commands; and, they ignore that we know perfectly well that some commands are used more often and that people have existing muscle-memory for these commands. Maybe a better approach would be to allow the user to customize which completions he prefers for a given prefix based on a lua hook? Can you demonstrate the existence of any user that actually wants di to mean disapprove? (Of course, one'd argue that checkout already has a shortened 'co' version, but that's not strictly a prefix of it...) See also mv, rm, ci, ls. And we've gotten bug reports when up accidentally stopped meaning update, and I'm sure would similarly if sy stopped meaning sync. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] set's erase() and iterators
On Tue, Oct 16, 2007 at 09:33:56PM +0200, Markus Schiltknecht wrote: Hello Will, on my box, monotone's suspend test reproducibly failed. Today I've tracked down the bug, which took me quite some time. Err... oops. I thought I fixed this on mainline a few weeks ago? Maybe it accidentally ended up in a branch instead... -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database compaction
On Wed, Oct 17, 2007 at 09:35:35PM +0200, Markus Schiltknecht wrote: I've recently been trying to implement some of the ideas from the database compaction wiki page [1]. Cool! == Compact Heights == As the wiki says, uleb128 wouldn't work too well, because compressed heights couldn't be compared with memcmp(). As I've had to do a lot with JPEGs recently, I've stumbled across Huffman encoding. Given a hand-crafted Huffman Tree, the memcmp() property could be maintained. But even though that idea fascinated me, and I've already begun to compile statistics about distribution of height values, I had to realize that the potential gain is very limited. As an example, my current working database is 618.1 MiB. Trimming all heights to a single-byte value - which is way too optimistic - results in a 612.8 MiB file. Maximum savings: less than 1% :-( Thus overly complicated things like Huffman are definitely not worth the effort. I didn't write any code here. I'm honestly not sure that we even get any benefit from using memcmp comparison on heights. I think the only way we use heights is to load them into memory, and if data is moving from sqlite into mtn proper than doing any kind of conversion on it is trivial and essentially free anyway -- I only brought up this memcmp comparison thing in the first place in case it let us do something clever with sqlite indices, and AFAIK we aren't. == Putting heights in the revisions table == I'm not sure why exactly heights haven't been stored in the revisions table from day one on, but I certainly think it's a good idea. It saves lookups and increases locality in case one needs the heights. And I don't think it hurts much if you don't. To check confirm or reject these assumptions, please refer to revision 45501e62. The tricky part about this is the regenerate caches stuff -- revisions are sacrosanct, because they give ground truth, while heights may get wiped out and regenerated. So the db needs to be able to represent here are all the revisions, none of them have heights assigned, and we need to be able to detect when the db is in this state. (And the logic around figuring out what state the db is in at any given time is already kind of convoluted :-/). If you've solved that, though, cool, it's probably doable. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] kibi!
On Mon, Oct 15, 2007 at 06:12:17PM +0200, Richard Levitte wrote: In message [EMAIL PROTECTED] on Mon, 15 Oct 2007 16:35:23 +0200, Lapo Luchini [EMAIL PROTECTED] said: lapo As it goes 1000 bytes is 1 kilobyte (1 kB) lapo while 1024 bytes should be called 1 kibibyte (1 KiB). That's what I would call newspeak... That's a strange stance, since kilo has meant 1000 back to at least the mid 19th century: http://www.bipm.org/en/si/history-si/ (Why are we talking about this on monotone-devel?) -- Nathaniel -- But suppose I am not willing to claim that. For in fact pianos are heavy, and very few persons can carry a piano all by themselves. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [BUG] merge_into_workspace fails on second merge attempt
On Fri, Oct 12, 2007 at 02:32:19PM +0200, Ralf S. Engelschall wrote: -I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()); [...] ...the merge_into_workspace command works just fine. I've reviewed even the results and everything looks just fine. Unfortunately, I still do not _understand_ why this assertion exists and why it is false only for merge_into_workspace. But I guess this assertion is from times before merge_into_workspace was invented and the workflow in the implementation of merge_into_workspace results in a special case which triggers the assertion. I don't know whether one can really _safely_ remove the assertion or not. Can somebody shed some light on us here? Ah, I see. Here's what's going on: left_uncommon_ancestors is the set of all revisions that are ancestors of the left revision being merged, but are not ancestors of the right revision being merged. (Compare to the notion of common ancestors; every ancestor of the revisions being merged is exactly one of common, left uncommon, or right uncommon.) Asserting that left_rid is in left_uncommon_ancestors, then, is asserting that left_rid is an ancestor of itself (which it is by definition) and that it is not an ancestor of right_rid (which is the point that's causing the problem). It does not make sense to merge an ancestor with its own descendent -- the descendent *already* contains everything that the ancestor has, plus it creates pointless merge nodes in the graph that prevent branches from converging. The other merge commands with more polished UIs contain special case code to detect this and skip entering the actual merge engine; merge_into_workspace ATM does not. (For instance, check out the code follow // check for special cases on line 510 of cmd_merging.cc.) So the short-term workaround for this case would be to just use 'propagate otherbranch thisbranch' or 'cert h:otherbranch branch thisbranch' instead of 'workspace_merge otherbranch thisbranch'. The long term solution is probably: -- if someone tries to do a workspace merge like this, then print a message and just update to the descendent version -- teach commit that if you try to do a commit with no changes, but the branch has changed versus the parent, then put that branch cert on the parent instead of just erroring out. -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
On Fri, Oct 12, 2007 at 11:12:15AM +0200, Markus Schiltknecht wrote: Nathaniel Smith wrote: If anything, it's probably on the late side to be organizing for January/February, so people probably would want to get on it quick... Yeah, better late than never ;-) Besides, are there any good reasons that it must be Jan/Feb? We could still do in in March or even April, no? No, no particular reason -- I think last year it just happened then because by the time we started planning it was too late to do it before Jan/Feb, and there was no reason to hold it off until after that. On further thought, a time after March 22 would be much better for me personally, because I'm a teaching assistant for the winter quarter this year, so that makes it quite tricky for me to get away between January 4 and March 22 (would need to find someone else to take my class, couldn't do it at all during test times, etc.). -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Wed, Oct 10, 2007 at 06:03:04PM +0200, Ralf S. Engelschall wrote: Ok, here is the final patch which includes the documentation update and a little corresponding test for make check. Any objections for comitting this? Looks fine to me. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone speedup by adding additional database indices?
On Wed, Oct 10, 2007 at 08:07:26PM +0200, Ralf S. Engelschall wrote: What do we think? Should we investigate further and especially add additional indices like the above to the Monotone database schema? Or is there consensus that this type of speed optimization is just the root of furthcoming evil and at least at this time should be still ignored at all... No way, 5x speedups for 1 line of code = ++good. And while once upon a time the database upgrade machinery was not savvy to indexes, that got fixed long ago (exactly to add some similar indexes, IIRC). We just don't revisit whether we have the right indexes very often :-). (This isn't to override any more specific problems people might raise in this thread, though I didn't see any obvious showstoppers so far.) [Err... though... waittasec. Shouldn't the database upgrade machinery be causing mtn to bomb out on your modified database (unrecognized schema version or the like)? Did you disable that or something?] I do wonder where the benefit is coming from in this particular case. The index on public_keys is almost certainly just irrelevant (though it doesn't hurt and adds scalability), since you probably don't have more than, say, 100 keys in there, and the whole table is almost certainly cached. And on revision_certs we already have: CREATE INDEX revision_certs__id ON revision_certs (id); CREATE INDEX revision_certs__name_value ON revision_certs (name, value); So if we add an index on (id, anything) we should remove the index on simple (id). But also that index on simple (id) should be making that search fast already, because once you've located the certs for a particular rev, then you only have to do a sequential scan over 4 of them (in most cases) to find any particular one. Perhaps sqlite's optimizer has gotten *too* smart and is picking the wrong index, doing a lookup by (name, value) and then sequential scan to match the id? ...It may not be worth answering these questions as opposed to just adding the stupid index, though. -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
On Thu, Oct 11, 2007 at 11:25:34AM +0200, Markus Schiltknecht wrote: Thomas Keller wrote: Is there a general interest of doing another summit next year - maybe again in January/February? LOL, I was just thinking about it and that we should start organizing such a thing if we are heading for the same time of the year... If anything, it's probably on the late side to be organizing for January/February, so people probably would want to get on it quick... You know I couldn't attend to the last / first one this year, but I'd really like to make it this time. But since I'm even more broken than last year all I could afford is something in Europe. Opinions? To be able to meet everybody in person, I'd favor a single event, as opposed to multiple local ones. OTOH that's certainly more expensive. Any chance of getting some sponsorship again? Maybe for an event in Europe? Asking Google Switzerland? ... If we can't get funds for a worldwide event, we should better try to organize local gatherings. But let's check for funds, first. I'm certainly willing to help organizing. My problem is that I'm probably not up to helping much with the organization this time -- I'll certainly be interested in coming, though! Sponsorship was very helpful, but it's not a necessary thing. The hard and urgent part is finding space and picking dates -- last year, of course, Google gave us space and some money towards lodging, so that determined the space part of things. (The other options I thought about were either borrowing space from a friendly company that is less massive than Google, which companies are much easier to find but it's much harder to get space during weekdays; or else lodging in a hotel that had free wifi and at getting one suite that could serve as a work area during the day.) (You also want to think about transportation issues -- in Europe I guess there is generally public transportation? Basically just making sure that there is some sensible way for people to eat during days without requiring elaborate load-everyone-in-a-car stuff. Google, of course, made this super-easy.) I would not be surprised if Google were willing to offer space again, or there are other options like above. I don't know that Google's non-Mountain View campuses are set up for anything like this, but I don't know that they aren't, either (though there'd be no Leslie there, obviously :-)). Whoever decides to make things actually happen would of course get to make final decision on all these things, Europe vs. other continents etc. :-) -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone speedup by adding additional database indices?
On Thu, Oct 11, 2007 at 11:17:17AM +0200, Markus Schiltknecht wrote: But I doubt very much that there are any gains. The index on revision_certs(id) should be enough, as we have only few (in most cases four) revision_certs per revision id. Measurement beats guessing :-). I'm not an expert reading these plans, but for sure both variants use an index scan and not a sequential scan. Thus I don't think it's worth changing these revision_certs indices. My question was which index it was choosing to use; it is trying to satisfy a constraint like A=1, B=2, C=3, and it can pick to either use an index on A then sequential scan for (B, C), or it can use an index on (B, C) and then sequential scan for A. (We do have an index on (name, value).) A plausible heuristic would be to use the index that lets you satisfy more parts of the constraint, but that heuristic would be wrong in this case, since in fact there are many certs with NAME=branch, VALUE=net.venge.monotone, but few certs with ID=da39... -- Nathaniel -- The best book on programming is still Strunk and White. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
Seems like you should just get commit access to me... Who's in charge of adding people to the server these days? Richard? On Mon, Oct 08, 2007 at 08:33:16AM +0100, Matthew Sackman wrote: This morning my mailbox was full of error reports - I wasn't caching the current time but looking it up twice and of course it can change. So he's a patch to fix that and I've also updated the README file for contrib. Could someone commit the patch please? Many thanks, Matthew -- Matthew Sackman http://www.wellquite.org/ # # old_revision [4c7504ea753f15bde2abc80e0e74dfc0951735e4] # # patch contrib/README # from [a5a965b9b3fed717621b8c216ec226756a95e568] #to [9c675c56a2e014932a16079f1a580b427c2cff15] # # patch contrib/monotone-mail-notify-standalone.lua # from [b451b8b6da1a0f92dcb9d372fe1935972f9eafaa] #to [f7912c79e41bff48c12b54e25bad92a03d5bc031] # --- contrib/READMEa5a965b9b3fed717621b8c216ec226756a95e568 +++ contrib/README9c675c56a2e014932a16079f1a580b427c2cff15 @@ -64,7 +64,10 @@ See individual files for licenses. for use. -- monotone-mail-notify-standalone.lua: a mail notification script which - runs without any other external dependencies than /usr/bin/mail and offers an individual per-branch recipient configuration with a syntax - similar to the one found in ~/.monotone/read-permissions + similar to the one found in ~/.monotone/read-permissions. + It writes out details of each revision received to files which are then + picked up by the monotone-mail-notify-standalone.sh script which requires + shell, source-highlight and mime-construct to build nicely structured + emails with summaries of the revision and its diffs. --- contrib/monotone-mail-notify-standalone.lua b451b8b6da1a0f92dcb9d372fe1935972f9eafaa +++ contrib/monotone-mail-notify-standalone.lua f7912c79e41bff48c12b54e25bad92a03d5bc031 @@ -133,9 +133,11 @@ do if j # (rev_data[certs][author]) then reply_to = reply_to .. , end end -local outputFileRev = io.open(_base .. rev_data[revision] .. os.time() .. .rev.txt, w+) -local outputFileHdr = io.open(_base .. rev_data[revision] .. os.time() .. .hdr.txt, w+) +local now = os.time() +local outputFileRev = io.open(_base .. rev_data[revision] .. now .. .rev.txt, w+) +local outputFileHdr = io.open(_base .. rev_data[revision] .. now .. .hdr.txt, w+) + local to = for j,addr in pairs(rev_data[recipients]) do to = to .. addr ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sun, Oct 07, 2007 at 09:58:14PM -0600, Derek Scherger wrote: Ethan Blanton wrote: I believe that it should; if it is more than just a few columns wide, it tends to make diffs and commit messages wrap on terminals they are meant to accommodate, and it displays an unfortunate tendency to be far more than a few columns wide. Even when it is correct, for Pidgin it often has 3-5 parallel lines at two columns apiece, and often it mistakenly draws O(a lot) of parallel lines. This seems fixable -- we know how wide the terminal is (the ticker code needs this), we know that the graph becomes *completely* useless when wrapping happens, so we can just teach monotone to do the Right Thing (i.e. disable the graph when it gets too wide, perhaps only for portions of time when it is too wide). There are a lot of other ways that the graphs are not as smart as they could be, and currently require --no-graph -- e.g., if you use --no-merges (like one of the examples upthread) then right now you basically have to use --no-graph. So that's easy to make right-by-default too. The other example given was as part of a hack to create a command that mtn should have anyway -- so when we add that command, that need for --no-graph will disappear as well. The graphs would also be more useful if log output were shorter (and esp. the merge output were less completely stupid than it is now -- showing every file touched on either side of the merge makes No Sense). Another thought. Maybe what we really need is something like .csvrc where you can specify the default options that you generally want with specific commands. I'm not sure how you would occasionally un-set options that were set like this though. This would be an easy way to make this problem go away, but I'm not convinced that it's the correct one. It seems to me that the problems with the graphs are more specific, and fixable as such. -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Mon, Oct 08, 2007 at 08:32:45PM +0100, Zack Weinberg wrote: It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... Before going this route, could you expand on hardwiring VT220 color control codes would be bad? Are there any terminals we actually care about that this would fail on? (Note that the grep and ls maintainers have both answered no to this question; search for the string '33[' in their source code. ls at least appears to also have a whitelist of $TERM values that are colorizable, dunno about grep.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sun, Oct 07, 2007 at 11:54:30AM -0700, Zack Weinberg wrote: This shows the log for all revisions in a branch but does not follow merges from other branches. (tac reverses the order of lines.) It's handy for reminding oneself what was done on an old branch that has seen a couple merges from mainline since the last actual change on the branch. I'd like to spell this mtn log --no-follow-merges. Wouldn't this be --stay-on-branch or so? This will happily follow merges that happened within a branch. -- Nathaniel -- The best book on programming is still Strunk and White. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007 at 07:09:03PM +0200, Ralf S. Engelschall wrote: So, find appended a small patch against h:n.v.m which implements a p:rev selector. With this I now can finally use short commands like: $ mtn diff -r p:rev -r rev The rev here can be an appreviated revision, too. The patch contains no tests, though otherwise looks reasonable enough. What happens if rev is a root revision? Show me stuff about revision blah seems like a pretty fundamental command -- stuff presumably including some metadata summary like log gives you, and also a diff or so. Does anyone have a good idea for what this command would be called? It would be pretty easy to add, and might solve your particular problem in a nicer way. (Also the commit notification problem that Matthew was fighting with, etc.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007 at 04:22:44PM -0400, Ethan Blanton wrote:
I know that I personally use 'mtn log --from rev --last 1 --no-graph
--diffs' *all* the time; a simple command which does this ('mtn
summarize' or the like) would be a boon, particularly if it could take
multiple revisions and output them in order.
Yeah, that's the point.
Of course, there is really no reason this can't be handled as a shell
alias or simple script, either...
Except that making users write their own code to fix our bugs is
stupid :-).
'summarize' still seems too long to type conveniently. Would 'show'
be too generic?
-- Nathaniel
--
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007 at 06:02:05PM -0400, Ethan Blanton wrote: Nathaniel Smith spake unto us the following wisdom: 'summarize' still seems too long to type conveniently. Would 'show' be too generic? I don't think it's too generic, necessarily, as I think one normally associates generic commands with operations on revisions, but it sort of seems funny in the presence of show_conflicts. I thought of 'view', but that's not so much a command to be performed as an action to be taken by the user, which might be a metaphor shear. show_conflicts should probably become something else in the long run anyway (merge --preview or something?), so that doesn't bother me, and I do like 'show' better than 'view'. Maybe we should just go with that. Anyone want to implement it? Should probably have almost no code of its own, just share code with log (which might need a touch of refactoring first to make that easy). -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
On Sun, Oct 07, 2007 at 04:31:01AM +0100, Peter Stirling wrote: I wrote a lua program that: Looks for revisions with 'bad' certificates (as reported by mtn au certs rev) which have private keys available to monotone (ie mtn au keys has a private_location), and Uses the mtn db execute command to delete the bad certs (all certs for that revision by that key because figuring out the hash of the bad certs was beyond me, however it does track all the good certs as well as bad for reinsertion), and finally, Uses mtn au cert rev to add the certs back to the database. If you wanted to be careful you might insert the new certs first, so in case the thing crashes for some reason then you end up with duplicate certs (recoverable) instead of no certs (not so much). But the idea seems right otherwise. -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
On Fri, Oct 05, 2007 at 10:07:49AM +0200, Benoît Dejean wrote: Let me explain better. I'm missing two public keys: - an old key of mine that i used to commit on this project. - a key from a another developer. I though the keys were stored in the database. My old key was surely in my ~/.monotone/keys but i think i deleted it because i no longer needed it. Maybe that was a mistake. But the developer key, i never touched it: i got this developer's revisions only by sync'ing. I don't understand. These branches are 1 year old. I don't understand either; for every cert in a db, we're supposed to also have the corresponding public key in the db. What does ls keys say? Does the server (that you and the other developer presumably sync with) have the keys? -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
On Fri, Oct 05, 2007 at 07:54:51PM +0200, Benoît Dejean wrote: I'm rebuilding right now. This makes me very nervous about silent database corruption :/ Don't be too nervous -- as far as we can tell, it is some sort of weird sqlite issue, and monotone doesn't actually trust sqlite not to clobber and corrupt data all over the place. (Mostly we are distrustful because sqlite is at the mercy of the hard drive, and hard drives/disk controllers/filesystems like to do that sort of thing all the time, but it applies to bugs in sqlite too.) I can only think of two problems where monotone wouldn't notice the issue and bail out before any further damage could be done. These are: -- if sqlite silently started forgetting about some certs or returning weird result sets somehow, then we might silently act as if those certs didn't exist, so e.g. you thought you had checked out the head of the branch but actually you didn't. No permanant harm done (you'll just have to merge up, just like you would have if you hadn't pulled those certs at all), but could be confusing. -- if something managed to corrupt the data in your workspace before we hashed it -- say from hard drive/filesystem issues, or very precise (and unlikely) memory overflow that silently corrupted the buffer full of data we just read, etc. -- then we would go ahead and commit the corrupted data. (Basically we couldn't tell this apart from you actually modifying the file in the given way and then submitting that to commit; corrupt is in the eye of the beholder.) You can do also 'mtn db check' if it makes you feel better; that runs all of mtn's high-level consistency checks, as well as sqlite's built-in ones. -- Nathaniel -- IBM manual SENG-5155-01: Power Supply and Air Moving Device Installation Instruction for iSeries 820 and 5075. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Bug Message
On Fri, Sep 28, 2007 at 11:32:34PM -0700, Zack Weinberg wrote: So - monotone isn't actually doing anything wrong, this is a bug in netxx. Is there any hope of getting it fixed upstream? I do not relish the thought of auditing the two-dozen or so places where netxx throws exceptions and fixing them to pay attention to errno. There is no netxx upstream -- he quit, and even the web page is gone. instead we should catch the various library exceptions that will cause program termination in the outermost catch chain (in cpp_main.) Kind of a layering violation, but *shrug*, there are probably a few different solutions of which any would work. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension Abstraction Layer
On Wed, Sep 26, 2007 at 07:53:16AM +0200, Ralf S. Engelschall wrote: On Wed, Sep 26, 2007, William Uther wrote: Or you could (in addition to dropping illegal certs) garbage collect any revs with no branch certs or no descendants with branch certs at the end of each sync. Yes, thanks that you mention this. This was one of our ideas, too. But we fair that this cannot be done reliably. Monotone in parallel serves connections, so if we garbage collect bad stuff at the end of a session the received stuff might be still already sent out again in a different session. The problem is that the sessions' data is auto-flushed to the database in smaller chunks and one not even can let one help by a database transaction here. That's why our idea is that it would be better if one already prevent the storage of bad revisions at all. If you have dropped the cert then mtn will not send out the revision (again, unless the revision has a descendent whose cert you accepted). -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Root directory name in inventory
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! :-) -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension Abstraction Layer
On Tue, Sep 25, 2007 at 08:35:35PM +0200, Ralf S. Engelschall wrote: On Tue, Sep 25, 2007, Markus Schiltknecht wrote: I'm not sure I fully understand what you are doing. From reading the patch, I think you are caching (in memory) one revision and it's certs until you can decide if it is acceptable, right? Do the certs of a revision always follow the revision in netsync? According to our discovery, in regular NETSYNC data flow: yes. But one could hack a Monotone client and force it to do it differently, so one cannot rely on this. In such a case monotone should (already) drop that cert -- the intent is that if a netsync operation is interrupted at any point, it leaves behind a fully consistent database, and one of the consistency properties is if we have a cert on rev R, we also have rev R. -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension Abstraction Layer
On Tue, Sep 25, 2007 at 08:24:11PM +0200, Ralf S. Engelschall wrote: Yes, we have not just considered this but if you look at the patch it is also implemented. Each Lua hook can return four value: accept, ignore, rollback:message and abort:message. Currently we are using mainly accept and rollback:message, but the approach you mentioned is achieved by returning ignore. Then the cert would silently be just ignored. Yes, I agree. My question is whether the 10-20 line patch to implement just this functionality alone would be sufficient to accomplish the goals currently aimed at by your 30kb patch :-). -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] Refactoring workspace API a bit
I think the net.venge.monotone.work-rev-refactor branch is ready for mainline. Would appreciate any comments, and also it totally changes the internal _MTN/revision-related APIs, so people might want to take note. The full patch is ~60 kilobytes because there are lots of callsites switched over to the new API. Not sending the full patch to the list, but if anyone wants to see it: mtn diff -r 133d7c3ff21229143d27ccd7cca5d64d2b117335 \ -r 3befc7cb6ed014757134d403ecf3618ec98e44d2 The important changes are in work.hh, and that part of the patch is attached. Rationale: Currently, when we modify the workspace, we do something like: 1) load the workspace roster (internally, this is done by loading _MTN/revision, loading the parent roster(s), and applying the csets in _MTN/revision to those roster(s).) 2) muck around with the workspace roster 3) load the parent roster(s) 4) use make_revision_for_workspace to calculate the differences from the parent roster(s) to the new workspace roster, as a revision 5) write the revision to _MTN/revision with put_work_rev This is inefficient (we load the parent roster(s) twice; often the roster cache will handle this, but still), poorly factored (the whole thing is open-coded all over the place instead of being encapsulated somewhere), and also it interferes with my Secret Plan (which is only secret at all because CIA is still down, but anyway). In the modified API, put_work_rev has become a private function, and get_current_roster_shape has (sort of) been removed. Instead we have two functions that complement each other: void get_work_state_shape_only(parent_map parents, roster_t ros, node_id_source nis); void set_work_state(parent_map const parents, roster_t const new_roster); The first is the same as the old get_current_roster_shape except that it also returns the parent map; the second encapsulates steps (4) and (5) above. Also there are a few other utilities like set_work_state_to_new_root(). -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender # # old_revision [133d7c3ff21229143d27ccd7cca5d64d2b117335] # # patch work.hh # from [49bf298fac3d660308c2b7106ff46854546401bd] #to [8f753ef66b7b0eb6402f9b132f79e2615d4aa00d] # --- work.hh 49bf298fac3d660308c2b7106ff46854546401bd +++ work.hh 8f753ef66b7b0eb6402f9b132f79e2615d4aa00d @@ -98,32 +98,44 @@ struct workspace void update_any_attrs(); - bool has_changes(); - // write out a new (partial) revision describing the current workspace; // the important pieces of this are the base revision id and the shape // changeset (representing tree rearrangements). - void put_work_rev(revision_t const rev); + void set_work_state(parent_map const parents, + roster_t const new_roster); + // For setup: + void set_work_state_to_new_root(); + // For checkout, import: + void set_work_state_unchanged(revision_id const parent_id); // read the (partial) revision describing the current workspace. void get_work_rev(revision_t rev); + // if this workspace has exactly one parent, give its revision id; + // otherwise, error out. + void get_unique_base_rid(revision_id rid); + // convenience wrappers around the above functions. + // This returns a map whose keys are revision_ids and whose values are + // rosters, there being one such pair for each parent of the current + // revision. + // + // Usually you will need both the parents and the current roster, in which + // case it is more efficient to use get_current_roster_shape (below). + void get_parent_rosters(parent_map parents); + // This returns the current roster, except it does not bother updating the // hashes in that roster -- the shape is correct, all files and dirs // exist and under the correct names -- but do not trust file content // hashes. If you need the current roster with correct file content // hashes, call update_current_roster_from_filesystem on the result of // this function. Under almost all conditions, NIS should be a - // temp_node_id_source. - void get_current_roster_shape(roster_t ros, node_id_source nis); + // temp_node_id_source. (It also returns the parent rosters, because this + // is free.) + void get_work_state_shape_only(parent_map parents, + roster_t ros, node_id_source nis); - // This returns a map whose keys are revision_ids and whose values are - // rosters, there being one such pair for each parent of the current - // revision. - void get_parent_rosters(parent_map parents); - // Inspect the workspace and classify all the paths in it according to // what ROS thinks of them. void classify_roster_paths(roster_t const ros,
Re: [Monotone-devel] 'undo commit' aka 'kinda-safe kill_revision'
On Tue, Sep 25, 2007 at 08:15:19PM +0200, Thomas Keller wrote: Very cool - I'll probably change the strings a bit to make them more user friendly and remove the I speak when it goes into nvm =) Hmm, tried to make them pretty clear, but if you have any ideas on how to improve, feel free. Btw... what is this branch about? Too many changes to get a clue through the diff... from what I can see so far it seems to become easier to get common data out of the workspace. See the thread I just started :-). -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension Abstraction Layer
On Wed, Sep 26, 2007 at 11:07:48AM +1000, William Uther wrote: Or you could (in addition to dropping illegal certs) garbage collect any revs with no branch certs or no descendants with branch certs at the end of each sync. Actual garbage collecting is hard, because it involves deleting things from the database. Remember that robust programming is like secure programming, except worse, because the enemy we are defending against is our own incompetence :-). Deleting things (esp. from something as complex as a delta-compressed cross-referenced store) is a Very Very Easy place to screw up, and then we lose data, and we can't do that, so... one would need very careful design to do this safely. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension Abstraction Layer
On Mon, Sep 24, 2007 at 10:40:55AM +0200, Markus Schiltknecht wrote: I'm thinking of the transaction multiplexing as a kind of a hack around sqlite's lack of fine grained locking (which would allow multiple concurrent transactions). Instead of adding yet another hack (manual redo log, sort of) I'd rather add support for a real RDBMS [1]. For the server side part of the netsync story, that would make things simpler and faster. I'm not sure the solution is as simple as that. Postgres isn't magic; are you sure you aren't just moving the problem around? Which transaction isolation level would you be planning to use? BTW: is netsync protocol documented somewhere? If not, I'm happy to create such a document, as I'm trying to figure out the details anyway. Just in the (occasionally exhausti(ve|ng)) comments in netsync.cc and netcmd.* -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] No windows buildbot?
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 is broken and we have never used it for actual releases in any case. So at the moment we have.. no automated testing on win32, and this is the platform that is most likely to get accidentally broken and also the one where such breakage is most likely to slip by us all unnoticed. Right. How is the Windows release built? MinGW: http://www.venge.net/mtn-wiki/BuildingOnWindows I don't have any windows in the house, unfortunately, so I can't exactly help directly, but it seems like this would be a good thing to fix? If we don't have testing, there's no way to guarantee that the next release of monotone will work on windows at all, and I suspect some people on this list would find that problematic :-). Yes, I would. I do try to run the testsuite often on my own machine, but that's not the same as a buildbot. Nope... a buildbot is much less effort for you :-). I have a machine that I'm intending to set up a Windows MinGW buildbot on. I've been waiting for better buildbot install instructions to show up, and for time to spend on it. The most recent set of emails about setting up buildbots was discouraging. The details of getting buildbot working on win32 is also something I'm not an expert on, unfortunately, but since we seem to have a working vs2005 buildbot already I'm sure someone around here knows how to do it :-). -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Non-modal merge
On Mon, Sep 24, 2007 at 06:15:47AM -0400, Stephen Leake wrote: The code that does this is in diff_patch.cc merge_via_edit_scripts. I don't fully understand how it works :). Adding this feature is probably more work that it's worth, since external diff3 with Emacs works fine for me. In the long run we should really get full merging stuff (including conflict marking) into mtn core, though, external dependencies like diff3 are a massive pain. In any case, monotone's diff algorithm is clearly different from diff3. Whether it's better in some sense is a separate question; for consistency, it might be worth using it for conflicts as I outlined above. I'll wait for other comments on this before doing anything. It's not very different, in principle -- they both find the longest common subsequence, which is a precisely defined mathematical concept. There are two reasons they might give different results, though -- diff3 has some heuristics to speed up running time when you don't pass -u (it doesn't *actually* find the longest common subsequence, just one that's... pretty long), and even if you do pass -u, there can be multiple different longest common subsequences, so just by chance two different algorithms will give different results. None of this really makes one superior to the other, the advantage is that calling out to diff or diff3 is tricky, fragile, and makes mtn harder to distribute. One data point; I have recently become dissatisfied with the results of the default merge that CVS does; it often gets the wrong result (by my criteria). So I'm hoping monotone does a better job - I haven't used it enough yet to tell for sure, but it hasn't done anything wrong yet. There are lots of cases where a merger will give less-than-satisfying results -- some will be shared between cvs and mtn's current mergers, some won't. Line merging is one of those things that's almost impossible to improve via airy theory, though; please please collect examples where it does the Wrong Thing, and if we collect enough we'll catch them all eventually, hopefully. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] No windows buildbot?
On Mon, Sep 24, 2007 at 08:32:50PM -0400, Stephen Leake wrote: Nathaniel Smith [EMAIL PROTECTED] writes: On Mon, Sep 24, 2007 at 06:32:41AM -0400, Stephen Leake wrote: How is the Windows release built? MinGW: http://www.venge.net/mtn-wiki/BuildingOnWindows Well, yes; I followed that. I meant; who builds it, on what machine? For the last while it's been Matt 'kinetik' Gregan, who's in the middle of moving -- dunno if that affects his ability to provide release builds. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Root directory name in inventory
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
{
// Not the root directory
st.push_file_pair(syms::path, i-first);
}
While I'm generally sympathetic to the idea of presenting the root
directory in some more user-friendly name, it seems a bit odd to have
an ad hoc user-friendly of writing it in a non-user-friendly
interface. Especially since it will still need special-case handling
by consumers of the API (no other directory name starts with ., for
instance), it isn't needed to make things parseable (since basic_io is
quoted, empty strings are perfectly easy to represent), and it
actually makes inventory inconsistent with the rest of the automate
API (I'm thinking in particular of things like 'automate get_revision'
and 'automate get_manifest_of').
Does anyone want to defend this, or should we just axe it?
-- Nathaniel
--
Eternity is very long, especially towards the end.
-- Woody Allen
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Commit Template
On Sun, Sep 23, 2007 at 02:12:33PM +0200, Ralf S. Engelschall wrote: Searching the parent dirs might be not the best idea. Agreed. For the remaining functionality the following does the trick for me: Index: std_hooks.lua --- std_hooks.lua 6ca29b67a6913342668b4cfa2464a37654615280 +++ std_hooks.lua 3852a7038c60e2389b3d1438906439794999d443 @@ -271,6 +271,13 @@ function edit_comment(basetext, user_log if user_log_message == or string.sub(user_log_message, -1) ~= \n then tmp:write(\n) end + local template_log_message = read_contents_of_file(.mtn-message, r) + if template_log_message ~= nil then + tmp:write(template_log_message) + if template_log_message == or string.sub(template_log_message, -1) ~= \n then + tmp:write(\n) + end + end tmp:write(basetext) io.close(tmp) Should we commit such a change or do we need a more sophisticated solution? This is broken, unfortunately -- e.g., if the user starts a commit, aborts it, then tries again, they will end up with multiple copies of the template in their log message. I think the right way would be to modify the after a successful commit or checkout, blank out _MTN/log logic so it becomes after a successful commit or checkout, either write the contents of .mtn-message to _MTN/log or else if that file does not exist then blank out _MTN/log. (Update is an interesting case here, since .mtn-message could change, but the user might have already written some stuff to _MTN/log. Maybe we should just add a check to see whether .mtn-message has changed during and update and print a warning to the user if it has, so they're at least aware.) What charset should .mtn-message be interpreted to be in, current user preferred charset or always-utf8? Always-utf8 seems more viable, though I'm sure it will bite someone at some point. -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Commit Template
On Sun, Sep 23, 2007 at 06:45:14PM +0200, Ralf S. Engelschall wrote: On Sun, Sep 23, 2007, Nathaniel Smith wrote: This is broken, unfortunately -- e.g., if the user starts a commit, aborts it, then tries again, they will end up with multiple copies of the template in their log message. Really? I tried it multiple times and I aborted by just using :q! from Vim and I never have seen the message accumulating. It worked just fine. The Lua function intentionally just copies .mtn-message into the _temporary_ file, not into _MTN/log. Yes, but on a failed/aborted commit, monotone saves whatever was written to the log message back into _MTN/log, so that when the user tries again after fixing whatever problem they had, their log message will pop back up. ...I don't know why that wasn't happening for you. For that matter, I don't understand how doing :q! would have aborted anything; it is supposed to abort only if the user has not written anything to the log, and in this case, it looks exactly as if the user *has* written something, i.e. whatever was in .mtn-message. This of course is a bug, the abort commit if log message is empty logic should be extended to abort commit if log message is empty or equal to .mtn-message, but I don't see this extension in the patch you posted. ...Or maybe if we implemented things the way I suggest, by copying .mtn-message into _MTN/log, then this wouldn't be necessary, because having _MTN/log non-empty triggers the thing where it wants you to confirm the commit by deleting a magic line. Dunno. Anyway, I don't understand the behavior you describe at all. [...] What charset should .mtn-message be interpreted to be in, current user preferred charset or always-utf8? Always-utf8 seems more viable, though I'm sure it will bite someone at some point. Can we control this in the Lua hook at all? I don't think so, the charset conversion stuff could in principle be exposed to lua, but IIRC it isn't ATM. I think the right place to do this is in the core _MTN/log / commit message handling code, though, as per above, and that code is already perfectly smart about charsets. -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension Abstraction Layer
On Sun, Sep 23, 2007 at 08:02:46PM +0200, Ralf S. Engelschall wrote: On my road of trying to adopt Monotone for use in my various larger Open Source projects like OSSP, OpenPKG, etc I've last week worked on an important issue (at least for me) which perhaps looks strange to the maximum distribution is everything which matters guys in the VCS camp: How to best combine the developer-requested distributed VCS nature of Monotone with the central ACL nature required at the master repository of those projects? To get you an impression how deep the problem is we try to solve here: we want that the developers can use full distributed VCS outside the central repository. Nevertheless, they have to fulfill a mandatory contributor agreement (to protect the licensing, etc) which especially means they are allowed to propagate/merge/pluck only revisions within a particular branch tree (e.g. openpkg.*) and inside this tree only developers who have signed the contributor agreement are allowed to commit their stuff. As long as a developer is fulfilling these constraints he will be able to share his revisions (which indirectly usually carry the revisions of others due to merging) with the master repository (from which official release tarballs and packages are rolled). If he breaks out of these constraints, he is _forced_ to stay out at all. Please do not confuse this with the idea of policy branches some of you already discussed. My understanding is that policy branches are about distributed policy _recommendations_, while I'm talking about central policy _enforcement_ here. So, this stuff is the other side of the policy branches medal. For a final solution one might wish both AFAIK. The policy branches are for the distribution, while our solution is for the master repository which usually is the middle of our proposed partial star topology. I think this is somewhat of a misunderstanding -- in some sense policy branches are indeed only recommendations, because I have no way to enforce what you do on your computer (short of crazy TCPA-like things). So I write down what policy I think we should all use, and then each contributor decides whether or not they will use that policy on their own computer. In practice, though, if everyone else is using that same policy, it's pretty useless to you to ignore it -- you can violate it in the privacy of your own server, but if you try to push those revisions to anyone else they'll either never receive them, or if they do then they'll silently ignore them anyway. Technically, then, enforcement comes from the other users of the project, but for most purposes we can just say that policy branches are enforced. I *think* policy branches are indeed trying to solve the same problem you are, just without making communication-time the one-and-only-chance to enforce security policies. That said, that's a hard (partially unsolved) problem, so if you need this stuff now, then it doesn't matter if policy branches can slice bread and do your dishes, they won't be ready in the immediate future and you might well want to keep on as you are :-). My partner Thomas Lotterer and I came up with the idea to solve the problem at the server-side of the master repository by directly enforcing the access control on keys, revisions, and certs during NETSYNC and even _ROLLING BACK_ the _WHOLE_ NETSYNC transaction in case an ACL fails. And I've now also developed an experimental implementation for this and I have written a little bit more about this stuff in my BLOG a few days ago (see the following URL for details: http://trainofthoughts.org/blog/2007/09/16/distributed-vcs-central-acl/). We are currently testing this stuff in practice with a few test repositories. Looks promising so far. You're going to have a problem with the transaction handling here -- the server does not and can not wrap a client connection into a single transaction. The problem is that the server is multiplexing across multiple connections at once, but with sqlite (and RDBMSes generally, to some extent) there is no way to have multiple parallel transactions open at the same time, to keep separate the data that's arriving in parallel from multiple clients. So the server commits regularly. Now comes the time where I would like to let you Monotone hackers review this stuff in more detail. The stuff mainly looks like this (see the attachments to this mail for a snapshot of this code): [...] Looks interesting, but no time to take a closer look right now. PS: If you think I like Lua just because I coded all this stuff in Lua, please see http://trainofthoughts.org/blog/2007/09/16/lua-popularity/ and give your feedback there, too ;-) Yes, the reason Lua is popular has nothing whatsoever to do with the language itself, and everything to do with the fact that the interpreter was designed from the ground up to be built into a larger C program. So it's one of the only
