[Monotone-devel] cvssync plans/status?
Hi all, It's been a long time since I've hacked on monotone. At work we use CVS for our development, and for a variety of reasons that's not likely to change. The group I work with would like to set up a sort of experimental development repository to allow us to hack on stuff that is potentially to destabalizing to live in the real CVS repo, but lets us collaborate easily while working on roughing out ideas, and would let us merge branches back into the CVS repo more easily when we find the direction we actually want to go. It looks like the nvm.cvssync is defunct, and nvm.cvssync.refactor has had changes merged from mainline (and also contains an experimental db-compaction branch?) as recently as spring of 2008 by Christof, nvc.cvssync.attrs was worked on spring of 2007 by Will. Is that a fair summary? Does anyone use any of these branches at the moment for working on code whose canonical repo is the CVS version? Are they stable enough for you? How much work remains to get something in shape to go into mainline? Thanks for any information, -emile (PS If anyone has had a good experience with another tool for this general use case I'd appreciate tips, although if we want to take it off list as not-monotone-related I understand.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
There's a link off of the monotone home page. It's channel #monotone on irc.oftc.net I think. -emile On Sat, Jan 17, 2009 at 8:16 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Where is the IRC? I can't find instructions for that on the mtn wiki (I _really_ miss the search facility there!). I have Jabber with an IRC backend installed on my Debian box; where do I point it? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: re-licensing the monotone manual
I am fine with anything I contributed to the manual being released under the GPL, v2 or later (although I don't think I have anything sufficiently substantive to matter). -Emile Snyder (And hi to all you monotone developers; long time no see. Hope all is well with everyone.) On Sun, 2007-02-18 at 18:42 -0800, Nathaniel Smith wrote: Currently, the main monotone manual, 'monotone.texi' in the source tree, is licensed under the GNU Free Documentation License (GFDL). Now, it turns out that this is a lousy license, that is probably not even DFSG-free[1]. It certainly has a whole host of obnoxious practical problems; in particular, it is never possible to move text from code into documentation, or vice-versa -- the GFDL and GPL are entirely incompatible licenses. So we want to change the license on monotone.texi to be GPL. This is a boring and annoying change to make, which is why we've been letting it slide for months and months, but... it really should happen. So. If you're getting this as a personal mail, it's because at some point you touched the monotone manual, and I ask you: PLEASE REPLY TO THIS EMAIL, CC'ING monotone-devel@nongnu.org, AND SAY THAT YOU ARE FINE WITH YOUR CONTRIBUTIONS TO monotone.texi BEING RELEASED UNDER THE GPL (v2 or later). Probably not everyone on this list actually made significant enough changes to have a copyright interest, but hey, it's easier this way... Cheers, -- Nathaniel [1] The question of DFSG-freeness is actually sort of complicated -- Debian as a whole does consider the GFDL to be DFSG-free (as long as you don't have any invariant section sections), but only because they had a whole general body vote on the matter, and that was the majority outcome. OTOH, the denizens of debian-legal, who presumably are the subset of Debian developers who actually know what they're talking about, overwhelmingly disagree: http://people.debian.org/~srivasta/Position_Statement.xhtml#survey Personally, I find the arguments that GFDL is non-free to be the most compelling. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug report: mtn annotate fails with wrong character case of the filename
Hi Vesselin, I worked on the annotate stuff alot back in the day, but haven't had much time to devote to monotone lately. So I'll do my best to figure this out, but I might not be able to give it the time it needs... You mention wrong character case of the filename in the subject; can you elaborate on what you mean there? Like, 'mtn annotate path/to/file.ext' works ok but 'mtn annotate path/to/FILE.EXT' doesn't? I'm trying to scrounge up a Windows 2000 box to test things on. Can you give me any more details that might help me reproduce this issue: do you have any un-checked in changes in the working copy where you tried this (assuming you tried from within a working copy)? Has the file in question been renamed/moved/recently added? Any funny characters in the name? Was the database recently rosterified? Thanks for the report, -emile On Thu, 2006-05-04 at 15:02 +0930, Vesselin Kostadinov wrote: OS: Windows 2000 I have a real file path/to/FILE.EXT in the monotone repository. mtn annotate path/to/File.ext mtn: fatal: std::logic_error: roster.cc:180: invariant 'fetching nonexistent entry from children' violated mtn: mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn --full-version', mtn: and a description of what you were doing to [EMAIL PROTECTED] mtn: wrote debugging log to C:/#/_MTN/debug mtn: if reporting a bug, please include this file * Note: the # bit has been edited mtn --full-version monotone 0.26 (base revision: unknown) Running on : Windows NT/2000/XP (5.0, build 2195) on ia32 (level 15, rev 521) C++ compiler: GNU C++ version 3.4.5 (mingw special) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_33_1 Changes since base revision: unknown A severely edited version of file debug is attached. All edits have been marked with #. Hope this helps. Regards Vesselin. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] renaming monotone executable (again)
Another vote for 'mtn' from me. Gut reaction to other contenders (in addition to all being poorer abbreviations): mt: name collisions are bad m: too cute mmm: too annoying to type moto: just don't like it ;) But none of the possible outcomes will make me howl with rage or anything. -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: multiple heads...
On Fri, 2006-03-03 at 22:37 +0100, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emile Snyder wrote: On Fri, 2006-03-03 at 20:56 +0100, Tim Ansell wrote: snip Say in CVS, when I create a branch called Mithro's Changes I now have two heads, the latest version of the main branch (which CVS refers to as HEAD) and the latest version of the Mithro's Changes. At any stage I can in theory merge the two branches back together (which is a pain under CVS that nobody actually does it). Exactly. With monotone, it's not painful at all. You can decide at commit time that your work belongs in a new branch, repeated merges work well, etc. etc.. This isn't completely true, they work well with 0.26pre using mark and merge, but not quite with 0.25 3-way algo. You're right of course; I should have been more careful in my phrasing. Two other things: * I'd really like a 'monotone patch-commit' command which I can feed a patch and it will add/drop/rename + commit the stuff inside. * lua hooks inside the repository, someone called it 'management branches', but I'd just like to ships some hooks inside OE. Noted. Thanks, -emile regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFECLcUMkyGM64RGpERAhDPAJ976qtL8XfYk9J83Qhg/khs9L5m7gCeMhfU yn9INJsDyYZgKKzjO9hXndA= =Aw52 -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] RE: cairo, git and mercurial
On Wed, 2006-02-08 at 13:46 +0300, Zakirov, Salikh wrote: ... git allows a more fully distributed model making it easier for users to pull (even speculatively with fetch) from multiple sources, track them in the local repository as separate branches and merge when appropriate. This is something that's also possible with Monotone. Mercurial makes this possible, but it's much more of a first class operation in mt and git. From the usability point of view, first class branches in Monotone has a disadvantage of being completely equal in rights. You can't just pull from remote reposotiry and start browsing the code, you will also need to find out which branch is the main one. This is true. I can think of two things that might ease this pain 1. Extend the netsync protocol so that you can easily ask the server what branches it's serving. 2. Also extend it so that it can show you branch groups, where a branch group is the set of branches which are attached to a single connected DAG of revisions. This would let you quickly see when there were multiple projects (ie. no overlapping code) in one repository. Would these changes make the co-equal first class branches more appealing to you? Apologies if this is straying to far afield from mercurial. I've cc:ed the monotone devel list, and discussion can continue there if it's more appropriate. -emile What's more, this full first class branch support can easily be overused by putting multiple unrelated projects in the same database. This does make harder to figure out what is what in the repository. IMHO, the most usable solution is * have one designated unnamed main branch * allow arbitrary number of named branches in the same repository ___ Mercurial mailing list [EMAIL PROTECTED] http://selenic.com/mailman/listinfo/mercurial signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] PATCH: embedded quote warning
Someone on IRC had an issue today where they did
monotone sync servername 'branchname'
and it pulled 0 revisions. They then tried
monotone sync servername branchname
and were successful. The were running monotone on windows; I seem to
recall someone else getting confused like this before as well.
Is the following patch an appropriate method of warning users that this
might be happening?
thanks,
-emile
#
# old_revision [b5ccb7aef03d1d54935ac57c76dc4056a0283a27]
#
# patch globish.cc
# from [9bb3f311393edb3c7bc58e64337e55bedd9549e7]
#to [b331af74203fab4c6befcab3de6233083971a283]
#
--- globish.cc 9bb3f311393edb3c7bc58e64337e55bedd9549e7
+++ globish.cc b331af74203fab4c6befcab3de6233083971a283
@@ -124,6 +124,19 @@
globish_matcher::globish_matcher(utf8 const include_pat, utf8 const exclude_pat)
{
std::string re;
+
+ if (include_pat().find_first_of('\) != std::string::npos)
+{
+ W(F(include branch pattern contains a quote character:\n));
+ W(F(%s\n) % include_pat());
+}
+
+ if (exclude_pat().find_first_of('\) != std::string::npos)
+{
+ W(F(exclude branch pattern contains a quote character:\n));
+ W(F(%s\n) % exclude_pat());
+}
+
checked_globish_to_regex(include_pat(), re);
r_inc = re;
checked_globish_to_regex(exclude_pat(), re);
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] per file DAGs in n.v.m.annotate
Hi all, I've been experimenting on net.venge.monotone.annotate with making annotate faster by keeping a DAG in the database of the revisions modifying each file. This could conceivably be used to speed up certain log operations as well (although at the moment it's just revisions which have content marks, and log would want rename or attribute changes as well.) annotate output using the new per-file-dags is not identical to the old annotate yet, so either the new one is buggy or the old one is, and either way I need to write new tests. Some preliminary performance numbers though: ~30 minutes to 'db filedagify' my monotone db (with all n.v.monotone* branches) new db is ~89MB, old one ~87MB annotate commands.cc: ~10minutes old, ~3minutes new annotate annotate.cc: ~6minutes old, ~11 *seconds* new So for young, relatively rarely changed files this is a big big win. But for the older, frequently touched files I'm not sure what the best way to get faster is. I haven't tested to see what kind of impact it has on commits on big trees with lots of changes but I can't imagine it's that bad. But it might make initial pulls a fair bit worse, depending on how much of that 30 minute filedagify is reading and parsing rosters vs. walking them and entering the node_revision_ancestry rows. Any comments or thoughts welcome. -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug in monotone automate inventory
On Thu, 2005-10-27 at 19:57 +0200, Jon Bright wrote: Emile Snyder wrote: No, this is clearly a bug in monotone. You created a legal file on your system in the working copy, and monotone choked and died. Thanks for digging and figuring it out, An interesting question - should monotone allow you to create any old filename, or should it restrict you to names with half a chance of being cross-platform compatible? I'd argue for at least the default to be the latter, on the grounds that I have no real opinion on this point; I was just saying that 'monotone ls unknown' should *never* die because of the name of any unknown file. If we can't print some filename as is, then we should escape characters in some appropriate way (handwaving here). When you try to 'monotone add' a file like that, it should perhaps disallow it (with some nicer error like 'monotone cannot handle control characters in filenames, not adding filename containing 0x07'), but again, shouldn't dump with an invariant triggered. thanks, -emile a) Almost no-one really, really wants that file to be called that (as in this case) b) Otherwise, monotone gets to play fun games when it tries to check that file out on a system that doesn't support that as a filename... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Promoting usher to become a standard utility
I vote for in tree, and part of standard releases. Serving multiple distinct projects a'la CVS from the same server comes up repeatedly on the mailing list as something people would like to do. If monotone's answer is to have a separate utility to do it (and I like what I've seen of usher so far too), then I think it should be as painless as possible to get going with it. Not, oh, yeah, go download this other package and... in the manual. best, -emile On Tue, 2005-10-25 at 12:13 +0200, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Mon, 24 Oct 2005 22:48:22 -0700, Nathaniel Smith [EMAIL PROTECTED] said: njs Another option would be to move it out tree entirely, as a njs separate add-on that implements the 'monotone usher interface' or njs something. Doesn't seem like anything that really gains a whole njs lot from shipping with monotone itself (except as sample code), njs since the user base for it is so special; and if it's turning njs into a full-fledged app, then maybe moving it out would give njs useful flexibility in terms of things like choosing an njs appropriate testing architecture... I would agree, except that there's a dependency on the supporting features in netsync, so it would probably be good to make sure that for any release, usher and monotone are in sync. Regarding how special the use base of usher is, I think that's a matter of opinion. I know a bunch of people who like the idea, and I'd like to hear the rest of the list express their opinion before we declare anyone special. njs (I swear, the grammar is viral. :-)) Heh :-) Cheers, Richard signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone disapprove does not give correct branch cert
Yuck. cert.cc:guess_branch(revision) defaults to using app.branch_name() if one is set; ie. you are in a working copy. There are 4 commands using guess_branch to decide how to cert a new revision: approve disapprove checkout commit I would argue that only commit should default to using the working copy value if one is set. approve and disapprove both take a revision as a specific argument; I can sort of see using the value of the working copy branch if that given revision has no branch cert, but not the other way around. Am I missing something? thanks, -emile On Tue, 2005-10-25 at 16:52 +0200, Wim Oudshoorn wrote: In our repository we have a few revisions with no branch certificate. It seems that they are caused by using monotone disapprove REVISION AFAICT monotone disapprove tries to figure out the branch from the current working directory and uses that branch to certify the disapprove node. If the command is given outside any working tree it does not give any branch certificate to the disapprove node. Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone disapprove does not give correct branch cert
On Tue, 2005-10-25 at 18:50 +0100, Bruce Stephens wrote: Emile Snyder [EMAIL PROTECTED] writes: I would argue that only commit should default to using the working copy value if one is set. approve and disapprove both take a revision as a specific argument; I can sort of see using the value of the working copy branch if that given revision has no branch cert, but not the other way around. I'm unconvinced that disapprove ought to do that. Surely it ought to use the branches that are on the original revision, maybe giving a warning if there aren't any? (I guess branchless revisions are unusual enough to merit at least a warning?) Overridable by the --branch option, I guess. I'm good with that. thanks, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] projects using monotone?
Hi all, I'd like to put together an 'early adopters' page for the monotone website that gives links to publicly accessible projects using monotone, along with some quick stats (size of db, number of committers, number of revs, etc.). Evaluating a tool is hard if you don't have any full-scale projects to use it on, so this would be a chance for people interested in monotone a chance to check it out by trying to use it to hack on real projects (besides monotone itself). It would also let people get a feel for the types of projects that have been comfortable migrating to monotone so far, and the sorts of issues they've had to deal with. So, if you are using monotone in some public capacity and wouldn't mind a little free publicity, send in a link! I also wouldn't mind notes from people that have tried to migrate to monotone but discovered they were unable to for some reason. What were the deal breakers? So far, between monotone-devel archives and google, my list is: xaraya colinux metatheme ctwm If you are one of these projects and *don't* want to be listed on such a page, please let me know that too. thanks, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] projects using monotone?
On Thu, 2005-10-20 at 13:46 -0700, Justin Patrin wrote: OpenEmbedded is using monotone currently. http://openembedded.org Looks like we currently have 39 public keys in our DB, although the # of regular comitters is 10 or less I think. We have 3+ servers set up to sync with each other and commit e-mails/rss/website going out via CIAbot. Our DB is about 200MB (or at least mine is, sizes seem to be different for different people). We have over 7000 files in the database. Cool, thanks for the feedback. From the website it looks like you don't allow anonymous read-only access to the monotone servers; is that right or did I just miss the link? -emile -- Justin Patrin signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] rfc on h: selector behavior
Hi all, Do people think that an h:branch selector to find the heads of a branch should accept globbing wildcard characters like the b: selector? So if you said a:bozo/h:com.circus.* it would select any head of a branch in the com.circus.* set authored by bozo. There has been concern expressed on IRC that globbing needlessly complicates things. Also, that it's not clear whether h:* should mean erase_ancestors(b:*) or union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) Any opinions? thanks, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Compiling from source
I believe I had exactly this problem on a newer redhat system at work. I don't pretend to understand exactly what's going on, but for me it appeared that /lib/tls/libc.so.6 didn't like exceptions at all (a trivial small test program that tried throwing and catching an exception died in the same way.) I managed to work around it by doing: LD_PRELOAD=/lib/libc.so.6 monotone (It looks like, from your ld output, that there's more /lib/tls libraries linked against your build than I had, I don't know if you would need to do this for all of them or what.) Hope it helps, or that someone who understands this better can pipe up, -emile On Thu, 2005-10-13 at 13:53 +0200, Zbynek Winkler wrote: Hello, I've managed to compile latest monotone (took about 45min) with gcc-4.0.2 (BTW: thanks the great INSTALL instructions!). Something changed since the last time I tried. Either gcc has improved in memory consumption or the sources changed in away that it takes less memory to compile (the last time I couldn't compile database.cc because 256MB of RAM was not enough). So hooray! And now the problem :(. Any command I try fails... $ ./monotone help terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create Aborted The gdb says: (gdb) run Starting program: /home/zbynek/devel/net.venge.monotone/_default/monotone [Thread debugging using libthread_db enabled] [New Thread -1212581376 (LWP 13938)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212581376 (LWP 13938)] 0xb7cdc5ef in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7cdc5ef in memcpy () from /lib/tls/libc.so.6 #1 0xb7e5d8ee in std::basic_streambufchar, std::char_traitschar ::xsputn () from /usr/lib/libstdc++.so.6 #2 0xb7e52c5a in std::operator char, std::char_traitschar, std::allocatorchar () from /usr/lib/libstdc++.so.6 #3 0x08061d4a in boost::io::detail::putchar, std::char_traitschar, std::allocatorchar, std::string const ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], loc_p=0xbfb88494) at feed_args.hpp:93 #4 0x080625ae in boost::io::detail::distributechar, std::char_traitschar, std::allocatorchar, std::string const ([EMAIL PROTECTED], [EMAIL PROTECTED]) at feed_args.hpp:233 #5 0x08062673 in boost::io::detail::feedchar, std::char_traitschar, std::allocatorchar, std::string const ([EMAIL PROTECTED], [EMAIL PROTECTED]) at feed_args.hpp:243 #6 0x082811b4 in cpp_main (argc=1, argv=0xbfb88d94) at format_class.hpp:64 #7 0x082837f0 in main_with_signal_handlers (argc=1, argv=0xbfb88d94) at ../main.cc:294 #8 0x082838db in main (argc=1, argv=0xbfb88d94) at ../main.cc:349 Do I have some library mismatch? ldd monotone says: $ ldd monotone linux-gate.so.1 = (0xe000) libz.so.1 = /usr/lib/libz.so.1 (0xb7f0e000) libdl.so.2 = /lib/tls/libdl.so.2 (0xb7f0a000) libboost_regex-gcc-mt-1_32.so.1.32.0 = /usr/lib/libboost_regex-gcc-mt-1_32.so.1.32.0 (0xb7e9) libboost_date_time-gcc-mt-1_32.so.1.32.0 = /usr/lib/libboost_date_time-gcc-mt-1_32.so.1.32.0 (0xb7e7d000) libboost_filesystem-gcc-mt-1_32.so.1.32.0 = /usr/lib/libboost_filesystem-gcc-mt-1_32.so.1.32.0 (0xb7e6b000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb7d9) libm.so.6 = /lib/tls/libm.so.6 (0xb7d6a000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb7d5f000) libc.so.6 = /lib/tls/libc.so.6 (0xb7c27000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0xb7c15000) /lib/ld-linux.so.2 (0xb7f2f000) librt.so.1 = /lib/tls/librt.so.1 (0xb7c0d000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0xb7b52000) I am running debian testing with boost-1.32. I also used aclocal-1.8 instead of 1.7 but except couple of warnings about some quoting issues everything went fine... Any help appreciated. Thanks. Zbynek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
On Thu, 2005-10-13 at 00:15 -0700, Emile Snyder wrote: Hi all, Do people think that an h:branch selector to find the heads of a branch should accept globbing wildcard characters like the b: selector? So if you said Ok, no one argued against it, there were a couple of lukewarm might be useful, and it preserves consistency. I'm gonna go ahead and check it in; if anyone feels it's the wrong choice it's easy to turn off. erase_ancestors(b:*) or union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) This seems like a thornier question. I still feel like the union() one follows the least surprise principle better. If anyone feels like the ambiguity of which it will do makes either answer surprising, we can turn it (globbing the h: value) off. Thanks all, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: rfc on h: selector behavior
On Thu, 2005-10-13 at 10:22 +0200, Wim Oudshoorn wrote: From a quick look in the manual I get the impression that: * All selectors accept globbing except: - date related selectors - ID selector This seems reasonable to me, dates and IDs have a very restricted format. So for consistency sake, I would accept globbing. Thats kind of my lukewarm argument too, and what I went with. erase_ancestors(b:*) or union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) Hm, difficult. I think I might lean towards the second case. Ditto, and for most of the same reasons. Head selector, how I would like to use it - On a related note, I imagine myself using a head selector most often in a situation after monotone sync. If after sync I get the message that I am not based on head I would like to be able to do some comparision. Scenario I: ... I have a checked out copy, without local changes, after synchronization I get a new head: Working copy -- Newly received head I would like to type something like: monotone diff --revision=h: So somehow you need to be able to specify the head of the branch of the current working copy. Huh, interesting. Not sure of the right way to do it, but I can see the desire to have it ;) Scenario II: I have checked out a copy and made local changes, which are not commited yet. Working copy --- Newly received head . working copy is changed on disk!! I would like to see the differences between the working copy revision in the DB and the new head. monotone diff --revision=i:$(cat MT/revision) --revision=h: Hm, is there a selector matching the current working copy? Well, if you want the current *contents* of the working copy, diff assumes that, but I don't think there is one for the revision in MT/revision. Scenario III: . I have a working copy and have commited local changes, which are commited: Ancestor --- Newly received head \ \--- Working copy I would like to be able to do something like, [fantasy syntax follows] monotone diff --revision=lca:(h:|i:$(cat MT/revision)) --revision=h: for the differences between ancestor and newly received head. Hmmm. I can see the desire for such a thing here too, but appropriate syntax totally fails me ;) Thanks for the feedback, -emile ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: rfc on h: selector behavior
On Thu, 2005-10-13 at 12:58 -0700, Nathaniel Smith wrote: Oh, yes, please -- I definitely think h:nothing should mean h:current branch... Ok, will do. (For that matter, perhaps b:nothing should mean b:current branch.) Can do that too. -emile ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] monotone serve --bind=addr:port patch
Hi all,
Below is a patch, per the venge.net/monotone/quickies.html list, to
change the monotone serve syntax from
monotone serve ADDRESS[:PORT] PATTERN ...
to
monotone [--bind=[ADDRESS:]PORT] serve PATTERN ...
where, if you leave out ADDRESS it listens on all interfaces, which is
also the default behavior if you leave out --bind entirely. Any
objections be me committing this? Problems with the documentation
change or anything?
thanks,
-emile
#
# old_revision [d96ca5cc69312da41e303fb8ec1f096ac6970aee]
#
# patch app_state.cc
# from [58db112140d05dcb5ffaea7e7eea44f04662312f]
#to [7fb51954421323439c2f12876ed81b71e7eaf634]
#
# patch app_state.hh
# from [b310058ad20b794c7b4347eb35d495b980f149cd]
#to [2ec009494567db9c8b00030a7bf18e089ba5195a]
#
# patch commands.cc
# from [c5293cbb4f245dffda5d6070c015405c159f55c4]
#to [dc66891c75b936926a1c841ef2358d41f1d6cd9b]
#
# patch monotone.cc
# from [bb6d6f0a31299f4d9848564c965f1d95eecb4827]
#to [f50b692ac580cf7cff3ddc11f27cbc5c1148d3c7]
#
# patch monotone.texi
# from [5b6a6b87eae80009ef88f9c5f58dddcea441c296]
#to [dc9a4ffcfa81f280cce66e7e90a88f180987111f]
#
# patch netsync.cc
# from [b85942e30b82c37025d535266b0f317718527b5a]
#to [ce285644b38da5591669e97b986c2cf5a287ff7f]
#
# patch netxx/address.cxx
# from [d10a78dd01637cc991e2bc3ab35c4570443d042d]
#to [4cab9d6c49a51edabcc3b74ca48ec0bd085e3dee]
#
# patch options.hh
# from [ac7bfa54b40a56f68dcdd40c83f994613aa7ab9f]
#to [e2be96021f06d474833fcb306e5a7cfea37ce52a]
#
# patch tests/t_netsync_single.at
# from [07187540f12b7fd8cf6ad91b02225c052745a011]
#to [aad7ba8fa47299d3c9ab357521166b6038364cd3]
#
# patch testsuite.at
# from [f665775bce51321c531198d61e90fe14ba56a107]
#to [299c060101e3207af910adf2800d010bd25fe038]
#
*** app_state.cc 58db112140d05dcb5ffaea7e7eea44f04662312f
--- app_state.cc 7fb51954421323439c2f12876ed81b71e7eaf634
***
*** 38,44
rcfiles(true), diffs(false),
no_merges(false), set_default(false), verbose(false), search_root(/),
depth(-1), last(-1), diff_format(unified_diff), diff_args_provided(false),
! use_lca(false), execute(false)
{
db.set_app(this);
}
--- 38,44
rcfiles(true), diffs(false),
no_merges(false), set_default(false), verbose(false), search_root(/),
depth(-1), last(-1), diff_format(unified_diff), diff_args_provided(false),
! use_lca(false), execute(false), bind_address(), bind_port()
{
db.set_app(this);
}
*** app_state.hh b310058ad20b794c7b4347eb35d495b980f149cd
--- app_state.hh 2ec009494567db9c8b00030a7bf18e089ba5195a
***
*** 62,67
--- 62,69
utf8 diff_args;
bool use_lca;
bool execute;
+ utf8 bind_address;
+ utf8 bind_port;
*** commands.cc c5293cbb4f245dffda5d6070c015405c159f55c4
--- commands.cc dc66891c75b936926a1c841ef2358d41f1d6cd9b
***
*** 1946,1974
utf8 addr,
utf8 include_pattern, utf8 exclude_pattern,
bool use_defaults,
app_state app)
{
// handle host argument
! if (args.size() = 1)
{
! addr = idx(args, 0);
! if (use_defaults
!(!app.db.var_exists(default_server_key) || app.set_default))
{
! P(F(setting default server to %s\n) % addr);
! app.db.set_var(default_server_key, var_value(addr()));
}
}
- else
- {
- N(use_defaults, F(no hostname given));
- N(app.db.var_exists(default_server_key),
- F(no server given and no default server set));
- var_value addr_value;
- app.db.get_var(default_server_key, addr_value);
- addr = utf8(addr_value());
- L(F(using default server address: %s\n) % addr);
- }
// handle include/exclude args
if (args.size() = 2 || !app.exclude_patterns.empty())
--- 1946,1978
utf8 addr,
utf8 include_pattern, utf8 exclude_pattern,
bool use_defaults,
+ bool serve_mode,
app_state app)
{
// handle host argument
! if (!serve_mode)
{
! if (args.size() = 1)
{
! addr = idx(args, 0);
! if (use_defaults
!(!app.db.var_exists(default_server_key) || app.set_default))
! {
! P(F(setting default server to %s\n) % addr);
! app.db.set_var(default_server_key, var_value(addr()));
! }
}
+ else
+ {
+ N(use_defaults, F(no hostname given));
+ N(app.db.var_exists(default_server_key),
+ F(no server given and no default server set));
+ var_value addr_value;
+
Re: [Monotone-devel] monotone serve --bind=addr:port patch
Color me impatient. I got one thumbs up on IRC, and the quickies file is supposed to be all uncontroversial items, so I committed. Just consider the email fair warning of the change in usage (it can bite you because the old command form is still valid, but it uses what you intend to be the address to listen on as another pattern for branches to export.) thanks, -emile On Tue, 2005-10-11 at 15:19 -0700, Emile Snyder wrote: Hi all, Below is a patch, per the venge.net/monotone/quickies.html list, to change the monotone serve syntax from monotone serve ADDRESS[:PORT] PATTERN ... to monotone [--bind=[ADDRESS:]PORT] serve PATTERN ... where, if you leave out ADDRESS it listens on all interfaces, which is also the default behavior if you leave out --bind entirely. Any objections be me committing this? Problems with the documentation change or anything? thanks, -emile ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Serving * does not work
Is your shell expanding *? I would think the command should be monotone serve 0.0.0.0 '*' -emile On Wed, 2005-10-12 at 01:17 +0200, Wim Oudshoorn wrote: When I server all branches with monotone serve 0.0.0.0 * I can not sync from other computers, I get an error something like: access denied due to branch xxx.yyy Using monotone version 0.23. Is this known? If not I will write a more detailed report. Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug in annotate, renamed files?
Is this in a project that you could let me see, or proprietary code? It would make it much easier to debug if I could do a pull of your project db. thanks, -emile On Sun, 2005-10-09 at 14:55 +0200, Wim Oudshoorn wrote: In one project containing 3 files the command monotone annotate file files on 2 of the 3 files. Both files that fail have been renamed in the past, but I am not sure that is the reason. Also both files give a different error. I tried this with version 0.20 and version 0.23 and both failed. The following description comes from version 0.23, the prebuild mac os x binary. Full version information is at the end of this mail. File one: e-monotone.el Error: monotone: fatal: std::logic_error: ../annotate.cc:550: invariant 'I(delta_entry_dst(fdelta_iter) == work_unit.node_fid)' violated monotone: monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to /Users/woudshoo/src/em-a/MT/debug Debug file ends with: do_annotate_node processing edge from parent 21454253c9477ac8b44c9de7b46c21e69c34456c to child a4660bef29785e139533ea07420d0857f45fac54 file wims-monotone.el in parent revision 21454253c9477ac8b44c9de7b46c21e69c34456c is wims-monotone.el ../annotate.cc:550: invariant 'I(delta_entry_dst(fdelta_iter) == work_unit.node_fid)' violated saving current work set: 0 items finished saving work set Full debug file: File two: e-monotone.texi Error: monotone: fatal: std::logic_error: ../annotate.cc:455: invariant 'I(file_interned.size() == other.file_interned.size())' violated monotone: monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to /Users/woudshoo/src/em-a/MT/debug Debug file end with: do_annotate_node processing edge from parent 21454253c9477ac8b44c9de7b46c21e69c34456c to child 4684e0611ebc668312162c3d8c01b7ec72d0e649 file wims-monotone.texi in parent revision 21454253c9477ac8b44c9de7b46c21e69c34456c is wims-monotone.texi parent file identical, set copied all mapped and copy lineage merging lineage from node 4684e0611ebc668312162c3d8c01b7ec72d0e649 to parent 21454253c9477ac8b44c9de7b46c21e69c34456c ../annotate.cc:455: invariant 'I(file_interned.size() == other.file_interned.size())' violated saving current work set: 0 items Full debug file: Full version information monotone 0.23 (base revision: e32d161b8d5cde9f0968998cc332f82f82c27006) Running on: Darwin 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh Changes since base revision: new_manifest [68895899b164e1f443f988efef93e8384f1b182a] old_revision [e32d161b8d5cde9f0968998cc332f82f82c27006] old_manifest [68895899b164e1f443f988efef93e8384f1b182a] Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
I like the idea of an .mt-attrs approach because the binary'ness of a file is a property of the file, not something that different people should have different ideas about (a'la hooks). I don't have particularly strong feelings about the right way to help monotone automatically figure it out for you, but I do feel strongly that there should be some way to explicitly tell monotone to treat a file as binary and have it do the right thing from then on. thanks, -emile On Wed, 2005-05-25 at 21:09 -0700, Nathaniel Smith wrote: On Wed, May 25, 2005 at 12:33:04AM +0200, rghetta wrote: If the hook returns nil, the file will be treated as binary if the monotone function guess_binary() returns true, i.e. if the files contains NUL bytes or a selection of other ASCII control chars (for example, STX and ETX). Another possible way to do binary support, for discussion: -- have the merger peek at .mt-attrs, and if a binary attribute is set on a file, consider it binary. (Currently nothing in .mt-attrs has hard-coded behavior, so this would be a change.) -- use the cool new attr_init hooks to automatically guess at add time whether each file is binary. -- never again automatically touch this attribute; let people set it to what they want, if they want Another possible way to do binary support, for discussion: -- just use guess_binary() on the data at merge time I don't tend to store binary files under VCS, so I don't have as much of an intuition about what the nicest way to do so would be; it'd be good to hear opinions from those actually affected by this :-) -- Nathaniel signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone update overwrites local changes
On Sat, 2005-05-14 at 21:21, Derek Scherger wrote: it seems to me that there are three settings for such a hook - fail on pre-existing files (cvs, svn, etc. do this) - preserve pre-existing files but continue (which I think would be useful occasionally) - clobber pre-existing files (what monotone does now) I'd like door number 4: move pre-existing files out of the way (foo - foo.bak.revid maybe?) and continue. thanks, -emile fail and clobber seem like the extremes and preserve seems like it might actually be a nice compromise. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel +-- flailover systems: when one goes down, it flails about until the other goes down with it. -- Rodger Donaldson +-- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone update overwrites local changes
See tests/t_add_stomp_file.at ;) -emile On Tue, 2005-05-10 at 10:52, Robert Bihlmeyer wrote: Suppose I have two working copies A and B, and an unknown file F in both. I then add A/F, commit this, and finally update B. monotone will trample over the contents of B/F overwriting it with the version committed from A/F. I don't think that's sensible behaviour, as update should not be a destructive operation. One option is to punt like CVS does and refuse to update unless B/F is moved away. More useful would be to initiate a two-way-merge between the repository version and what's already there. The latter is already done when I do monotone add B/F before updating. (A middle-of-the- road solution would be to punt with a reminder that one can either move F away or add it to get merging behaviour.) +-- The Two Phases Of University Employment: 1. Doesn't know enough to get a Real Job. 2. Knows too much to want a Real Job. -- sharks +-- signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [patch]move attributes on rename
On Mon, 2005-05-02 at 10:48, Timothy Brownawell wrote: On 5/2/05, Henrik Holmboe [EMAIL PROTECTED] wrote: Nathaniel Smith [EMAIL PROTECTED] writes: snip command-specific-option. For this to be acceptable, though, I think on drop we'd have to cache the deleted file somewhere, for disaster recovery. I would suggest that Monotone shouldnt contain a built-in Traschcan, for the very same reason rm doesnt. Doesn't it already, in the form of monotone revert filename? Not for all situations; if you 'monotone drop foo' and foo had some changes that were not checked in yet, then revert doesn't help you much. -emile +-- Pauli's exclusive, Heisenberg's uncertain and Schroedinger just waves -- Caton Little +-- signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Thoughts about 'testresult'...
On Thu, 2005-04-21 at 00:55, Richard Levitte - VMS Whacker wrote: ...snip... I'm proposing to change that behavior by making things more explicit. Instead of getting implicitely stuck on revisions with true testresult certs, there should be a way to explicitely ask to get only those. As fat as I can tell, the simplest way would be with another selector. Since we're talking about results, I propose 'r', with the following format: r:keyid So, what commands would use this, and how would the final behavior differ? Does update now never update you to a rev with a true testcert *unless* you give it this selector? That seems counter-intuitive in the other direction. keyid would simply be the key with which the testresult cert has been signed, since that key is supposed to represent the test that has been successfully performed. Comments? Is this a completely wacky idea, or would people like this (I would, most obviously)? r: makes me thing revision, is t: taken? thanks, -emile Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. +-- This `telephone' has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us. -- Western Union internal memo, 1876. +-- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] cvs_import/sync questions
Hi all, Is it worth looking at cvs bugs on the main branch, or is the cvssync branch going to supersede it? Is cvssync close to merging? Is cvssync stable enough that I should try to figure out bugs on it, or is it still in flux and I should just let Christof do his thing? thanks, -emile +-- Bother, said Pooh, Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three. -- Robert Billing +-- signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: resend: cvs_pull bug and test for n.v.m.cvssync branch
On Mon, 2005-04-18 at 05:36, Christof Petig wrote: ... I imported the test. But currently I have a problem of zombie revisions appearing on cvs_pull (currently dead files reappear). I'll tackle the problem later this week (sorry) No sweat, just wanted to make sure it got through to you. thanks, -emile Christof +-- A train station is where trains stop. A bus station is where busses stop. A Work Station is where... +-- signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
