[Monotone-devel] Botan2 support?
Hi, as Botan 1.10 has gone EOL 2018-12-31 [1], has anybody already looked into porting Monotone to Botan 2.x? Starting with Fedora 31, there will be no compat-openssl10-devel package anymore, and thus no Botan 1.X (unless we disable the OpenSSL module there), and that in turn affects the monotone package. - Thomas [1] https://botan.randombit.net/handbook/support.html ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-users] CAD versioning
Hi Hugo, Really?? It would be a surprise to me that monotone's delta algorithm would only be efficient for text files, because I have been using monotone for many years on images and pdf files without problem regarding performance. I thought monotone uses xdelta, which is a binary delta algorithm that facilitates binary merges that can be easily applied to both text and non-text files. Am I right, or is monotone's delta algorithm only efficient for text files? These are two different things. The fact that Monotone uses xdelta to efficiently store different versions of a file is an implementation detail, that is not (should not) be visible to the user (well, besides the fact that it saves disk storage). An automatic merging attempt on the other hand happens whenever there's a conflict for text files to be solved, and this merging attempt is line-based. Do not confuse them, they have nothing to do with each other. That said, if I remember correctly, one could hook in any other method for trying an automatic merge in case of a conflict on file contents, and that method could in theory also handle binary files (like zipped xml and the like). Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz colours
Hendrik Boom hend...@topoi.pooq.com: monotone-viz is giving me a nice display. But is it documented somewhere what the pretty colours mean? And whether boxes are outlined with solid or dotted lines? Same color means same comitter (or author, not sure). Boxes with dotted lines are from different branches and a double click on such a block switches to a view of that branch. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Fwd: Monotone and ViewMTN
Konstantin, which version of ViewMTN are you running? For monotone = 0.46 you should use the latest devel version, which is available e.g. here: https://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone.viewmtn/ Regards, Thomas M. Am Tue, 17 May 2011 10:43:54 +0200 schrieb Thomas Keller m...@thomaskeller.biz: Could somebody please have a look at Konstantin's problem? I'm unfortunately quite busy currently. Thanks, Thomas. Original-Nachricht Betreff: Monotone and ViewMTN Datum: Mon, 16 May 2011 19:41:33 -0700 (PDT) Von: Konstantin Minevsky k.minev...@yahoo.com Antwort an: Konstantin Minevsky k.minev...@yahoo.com An: m...@thomaskeller.biz m...@thomaskeller.biz Greetings, Thomas! I was looking for help all over the Internet, but with no success. I hope you can shed some light on my problem. I've got Monotone (0.48) installed along with ViewMTN on Debian Squeeze box. Everything was working fine before update from Lenny to Squeeze. But now our ViewMTN page shows nothing: http://mt.xaraya.com/ Logs show nothing, except Apache2: FastCGI: server /var/www/xaraya/mt.xaraya.com/viewmtn.py stderr: 'exception writing to child process; attempting restart: Traceback (most recent call last):\\n File /var/www/xaraya/mt.xaraya.com/mtn.py, line 168, in __run\\n self.process.tochild.flush()\\nIOError: [Errno 32] Broken pipe\\n' Could this be a reason for a blank page? Best regards, Konstantin -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 1.0 released
Am Sat, 26 Mar 2011 13:39:42 + schrieb CooSoft Support supp...@coosoft.plus.com: I tried building from source and my binary went bang (illegal instruction). This is what has happened since about 0.48, I'm sure I'm doing something wrong but it's not obvious (dependencies are met or so it seems). I normally download the binary from the site now. Any idea when the mtn-1.00-linux-x86.bz2 file will be ready for downloading? There's a binary available on the download page now, please test. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 1.0 released
Am Sat, 26 Mar 2011 13:39:42 + schrieb CooSoft Support supp...@coosoft.plus.com: I tried building from source and my binary went bang (illegal instruction). This is what has happened since about 0.48, I'm sure I'm doing something wrong but it's not obvious (dependencies are met or so it seems). I normally download the binary from the site now. Any idea when the mtn-1.00-linux-x86.bz2 file will be ready for downloading? Working on it, should be there in the evening. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release Of Monotone Browser 0.72 And Monotone::AutomateStdio 0.12
Am Tue, 22 Mar 2011 11:54:17 +0100 schrieb Thomas Keller m...@thomaskeller.biz: Am 13.03.2011 10:28, schrieb CooSoft Support: Good point. It does seem a little bit 'odd' that a Gtk tool has a dependency on KDE. So unless anyone has any objections, I'll switch to meld. Remember that this setting just specifies the default application to use, the user is free to change it under their own preferences to what ever they want. So I think this is more an issue for packagers... Please let me know if you don't like this decision. As I said I'm ok with it and Thomas Moschny is probably the same. Of course, since I proposed that change. Thinking of it a bit more, it might (from a packager's point of view) even better if the diff tool wasn't required at build time at all, in order to not populate the build chroot with stuff that's not actually needed for building. Thomas M. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release Of Monotone Browser 0.72 And Monotone::AutomateStdio 0.12
Am Sat, 05 Mar 2011 15:05:01 + schrieb CooSoft Support supp...@coosoft.plus.com: Just a quick email to announce the release of the above software on source forge and CPAN respectively. Basically the main work was to get these packages working with version 0.99.1 of Monotone. Monotone Browser, not only having the new selectors introduced in 0.99.1, also now has the ability to restrict revision and file histories to specific branches. Just fyi, Fedora packages have been put up for review: https://bugzilla.redhat.com/show_bug.cgi?id=684407 https://bugzilla.redhat.com/show_bug.cgi?id=684433 Btw, I changed the default FILE_COMPARISON tool from kompare to meld, to not drag in too many KDE packages for Gnome user. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] viewmtn status
Hi Brian, the development version [1] should support the stdio format from monotone 0.46 and later. Regards, Thomas [1] mtn clone 'mtn://code.monotone.ca/contrib?net.venge.monotone.viewmtn' Brian May br...@microcomaustralia.com.au: Hello Is viewmtn still maintained? Still working? I am having problems, it seems that it receives the data it expects from mtn stdio, and then blocks forever on a select statement. I tried running the same stdio automate calls by hand and they seem to work fine. Later: hmmm... Looks like this regexp is broken: packet_header_re = re.compile(r'^(\d+):(\d+):([lm]):(\d+):') which is expected to be parsed as cmdnum, errnum, pstate, length = m.groups() The data returned by mtn stdio is: 0:m:40:au.com.microcomaustralia.website.themes 0:l:1:0 So I think maybe the format of stdio has changed since viewmtn was last updated. This is on a Debian squeeze system. -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Markus Wanner mar...@bluegap.ch: On 11/24/2010 03:20 AM, Timothy Brownawell wrote: Also from IRC we have: thm_ the whole release numbering discussion is not meaningful wrt rpm, as Fedora for example has its own rules, forbidding non-numerics in the version part of an rpm. Really? There are so many open source projects with non-numeric versions that I distrust this statement. The first Google hit I get seems to indicate that non-numeric versions are perfectly supported in Fedora as well, see [1]. Time for a clarification of my note on IRC. The well-known-to-Fedora-packagers website you are citing says, that because of the ordering problems, a Fedora package may *not* have non-numeric parts (besides the dot, obviously) in the *version* part of an RPM name. The website therefore deals with the question where to put these non-numeric parts of a version number so many upstream projects make use of: For any Fedora RPM they have to be put in the *release* field of the RPM name, but prefixed by a number (and even two numbers in case of a pre-release, the first of them being zero.) For example, upstream uses: monotone-1.0rc1, and this is intended to be a pre-release, then the first-attempt Fedora package would have to be called monotone-1.0-0.1.rc1, the second attempt monotone-1.0-0.2.rc1, the next release candidate maybe monotone-1.0-0.3.rc2, the final 1.0 package monotone-1.0-1, and a later devel package from trunk monotone-1.0-2.20110229mtncafebabe. So in short, what this packaging guideline basically does, is forcing the maintainer to *manually* ensure proper ordering via the release field. Therefore, it is irrelevant what version scheme we (as monotone upstream) come up with, I (as Fedora monotone packager) might have to adopt it anyway to be consistent with the packaging guideline, so we don't *need* to discuss (or take into account) any particularities of RPM version number ordering here on this list. Hope that clarifies it a bit, Thomas -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] server move?
Am Sun, 31 Oct 2010 17:15:29 -0400 schrieb Hendrik Boom hend...@topoi.pooq.com: On Sun, Oct 31, 2010 at 09:57:44PM +0100, Richard Levitte wrote: You're entirely correct, the information on that page is incorrect. If you run mtn 0.48 (or possibly older, haven't really tried), this will work: mtn 0.40 fails to recognise mtn: hend...@april:~/monotone$ mtn --db=monotone.db pull mtn://monotone.ca/monotone net.venge.monotone* mtn: doing anonymous pull; use -kKEYNAME if you need authentication mtn: connecting to mtn://monotone.ca/monotone mtn: network error: service name resolution failed for: mtn Try mtn --db=monotone.db pull \ monotone://monotone.ca/monotone net.venge.monotone* instead, or add an entry for mtn to /etc/services. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] server move?
Hendrik Boom hend...@topoi.pooq.com: So I guess that I'll have to wait for 0.99.1. I gather that's one of the high prio items. Hmm. Maybe 0.99 will work on my less up-to-date machine. I'll try that if I turn out not to be able to wait. Forgot to add this: You can always use the stand-alone binaries from the monotone.ca download page. They don't need to be installed (just bunzip and copy to $PATH) and should work on any x86 Linux where a 32bit glibc 2.3 (or later) is available. They don't need any other libraries. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] server move?
Hendrik Boom hend...@topoi.pooq.com: Forgot to add this: You can always use the stand-alone binaries from the monotone.ca download page. They don't need to be installed (just bunzip and copy to $PATH) and should work on any x86 Linux where a 32bit glibc 2.3 (or later) is available. They don't need any other libraries. Does that mean it's statically linked with a nontoxic version of sqlite? The latest binaries there are linked against sqlite 3.5.9. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] monotone 0.48.1 released
Hi! This is to announce that we, the monotone developers, have released version 0.48.1 of our distributed version control system. While we are heading towards 1.0 and still planning to release 0.99 in the near future, we found an issue that is security related and thus warrants making a bugfix release: In monotone 0.48 and earlier, running mtn '' or mtn ls '' caused an internal error. This could be misused to stop a server remotely (but only if it was configured to allow execution of remote commands). This has been fixed on mainline and in 0.48.1. Therefore everyone running such a server should update as soon as possible. Please check as always the NEWS file [0] for a detailed list of changes and improvements. Binaries will be posted as they come in and will be retrievable from the downloads page [1]. Thanks for your time, Thomas. [0] http://monotone.ca/NEWS [1] http://monotone.ca/downloads.php ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Please review nvm.man-page
Stephen Leake stephen_le...@stephe-leake.org: This almost works (from bash under Emacs), but it loses all the headers: function get_man_page_formatter_command() local term_width = guess_terminal_width() - 2 local path = c:/bin -- On MinGW, 'popen' runs 'cmd.exe' with the inherited path; run Cygwin bash from there return string.format(bash -c nroff -man -rLL=%dn | less -R, term_width) end Problem is that you need to pass exactly one argument to the -c option, so quoting is to be used: return string.format( bash -c 'nroff -man -rLL=%dn' | less -R, term_width) works, at least under Linux. Otherwise, the -man and -r options are consumed by bash, not nroff. But then, me wonders where 'path' is used? - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Please review nvm.man-page
Thomas Keller m...@thomaskeller.biz: Comments are welcome. Most things have already been said by others. * I'd like to see the section headings in the generated man page to be localized, too. * in 'interactive' mode, nroff is called with -Tutf8, but not all locales use utf-8, so this should instead be locale-dependent. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz workaround for a bug in recent graphvizs
Committed to nvm.monotone-viz and nvm.monotone-viz.new-stdio. Regards, Thomas Thomas Moschny thomas.mosc...@gmx.de: Hi Olivier, this patch seems to work fine here, and I'd like to commit it on nvm.monotone-viz. Any objections? Regards, Thomas Stéphane Gimenez d...@gim.name: Hi monotoners, Quoting debian bug #563634, you may have found revisions nodes displaced with respect to the edges connecting them in monotone-viz display. In fact, dot's -y option appears to be broken recently. An alternative is to use rankdir=BT. It is more natural and hopefully solves the issue. Here's a patch for monotone-viz. Stéphane ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz workaround for a bug in recent graphvizs
Francis Russell fran...@unchartedbackwaters.co.uk:
Just one thing, is there any particular reason why the patch changes
the shell dot runs under to bash?
The shell is only used in debug mode ('if Viz_misc.debug dot').
Otherwise, dot is called directly. And the 'pipefail' option is
probably not supported by (any) sh, but it is by bash.
Also, if you do decide to commit it, could you please propagate to the
new-stdio branch as well?
Sure.
Regards,
Thomas
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] net.venge.monotone-viz.net-stdio
Hi all, Francis Russell fran...@unchartedbackwaters.co.uk: Hi Stéphane, a while back you sent me a patch against revision 142b487d0b2cc5e24e17998407f7921f2372ea3c in the new-stdio branch of monotone-viz to fix a parsing bug. I was wondering if this patch was available anywhere in a monotone revision? Ideally, it would be nice if it was available as part of the new-stdio branch on monotone.ca. I'm looking to get the Debian monotone-viz package working again and it would be nice if I could simply point to a commit on the new-stdio branch as the source of my patch. Committed as b34ff2e695b53c2d73d533a3ffa7cb081b48eefb on branch net.venge.monotone-viz.new-stdio. Regards, Thomas -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz workaround for a bug in recent graphvizs
Hi Olivier, this patch seems to work fine here, and I'd like to commit it on nvm.monotone-viz. Any objections? Regards, Thomas Stéphane Gimenez d...@gim.name: Hi monotoners, Quoting debian bug #563634, you may have found revisions nodes displaced with respect to the edges connecting them in monotone-viz display. In fact, dot's -y option appears to be broken recently. An alternative is to use rankdir=BT. It is more natural and hopefully solves the issue. Here's a patch for monotone-viz. Stéphane -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] OS-specific line endings
Am Sat, 03 Jul 2010 19:12:40 +0200 (CEST)
schrieb Richard Levitte rich...@levitte.org:
The usual problem is there, how to make certain we don't do
conversions with files that should be seen as binary but aren't
obviously so from a technical point of view.
That's the easy part: don't do anything per default, and do line ending
conversions only if the file has some 'eol-style' attribute set.
The not-so-easy part is to get all corner cases right. SVN needed
several versions for that, iirc, but now has a working solution, which
might be worth to look at.
It works like this: A file can have the 'eol-style' attribute
('property' in SVN speak) set to one of 'native', 'CRLF', 'LF' or
'CR' (where 'native' means the line ending style of the OS the
Subversion client is currently run on).
Now, if that attribute is set, Subversion ensures that the file in the
workspace has exactly that line ending scheme (and uses some normalized
format [namely LF] inside the repo, but that's basically transparent to
the user).
This however has a side-effect, which may be unexpected at first sight:
During a commit, the file *in your workspace* may change, so that after
the commit, the line ending scheme matches that specified by the
property.
If at commit time a file has the 'eol-style' property set, but has
inconsistent (i.e. mixed) line-endings, the commit is rejected.
Again, Subversion needed some time to get it right, and we should avoid
hitting the same issues they did. Any ad-hoc solution might give us
headaches later.
Regards,
Thomas
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mismatched SHA checksum
Am Mon, 14 Jun 2010 21:21:17 -0700 schrieb Arthur A. Gleckler monot...@speechcode.com: This morning, I downloaded 0.48 for Linux (mtn-0.48-linux-x86.bz2) and the SHA checksum matched. I just downloaded it again on two other computers, and in both cases, the checksum didn't match. I don't have access to the first computer right now to compare files, but I'm wondering if this is a mistake or something sinister. Was that binary supposed to have changed this afternoon? Sorry, that's my fault. I uploaded the binary twice, because the first version still had a glibc-2.4 symbol in it (and we claim to be compatible with glibc-2.3). After the first upload, the caching logic on the website remembered the sha1 sum of that file, and I wasn't able to convince it to refresh it after the second upload. The correct sha1 is: 84e72fb610418d848fc1ebe2b3821932cce6c38e mtn-0.48-linux-x86.bz2. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mismatched SHA checksum
Am Tue, 15 Jun 2010 09:24:05 +0200 schrieb Thomas Keller m...@thomaskeller.biz: When the binary was uploaded, it might have already been looked at through the downloads page and because of that a wrong checksum of a partially uploaded file was calculated and cached. This cache invalidates itself after 24 hours, so it should be correct in a few. The file was indeed uploaded twice, intentionally, as I explained in my other mail. Sorry for the inconvenience - I start to think I should remove this dynamic hashing again altogether... We could use file time and size to determine whether the sha1 sum has to be regenerated (same as the mtn inodeprints code does). For security reasons though, it would be best to not automatically regenerate the checksums. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.99, 0.999, ...
Am Mon, 14 Jun 2010 10:33:57 -0400 schrieb hend...@topoi.pooq.com: When monotone started, did it start as 0.01, 0.02, ... 0.09, 0.10, 0.11, ... or did it start 0.1, 0.2, ... 0.9, 0.10? If the former, we're using two-digit integers, but they could be interpreted as rationals, so we haven't run out. If the latter, the next would be 0.100. The first commit in my db here (on 2003-09-04, from Graydon) has the commit message: 0.4 release. So, from that point of view, 0.100 would indeed be the next after 0.99, if we don't want to release 1.0. But we should try to avoid going that route again. - Thomas -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am Fri, 04 Jun 2010 01:45:44 +0200 schrieb Thomas Keller m...@thomaskeller.biz: While I'm going to manage the upcoming 0.99 and 1.0.0 releases, I'd like to give my release manager hat to somebody else afterwards, so I can concentrate on other things a bit more. I'm not out of the world, so whoever wants to take the job can of course count on my help. Thanks for doing the job for a so long time now! Doing releases does not involve much - the process is fairly good documented. Perhaps the most important skills are a bit of a passion for the software and some accuracy :) So, who's up for the job? If no one else is interested, I'd volunteer. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Stephen Leake stephen_le...@stephe-leake.org: Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. MinGW uses (i.e. provides headers for) the standard C runtime as provided by the Windows OS. And as far as I understand, there's simply no strptime() in that runtime, so we have to provide our own implementation (which basically means copying one of the various versions already provided by other open source projects). -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am Wed, 28 Apr 2010 09:40:23 +0200 schrieb Thomas Keller m...@thomaskeller.biz: I think I have to find another shell... $ echo mtn://foo.com#foo zsh: no matches found: mtn://foo.com#foo So if its only zsh and whatever I try here needs escaping anyways, we can simply stick to the more common ? then... set nonomatch in ~/.zshrc does help: [tho...@localhost ~]% echo mtn://foo.com#foo mtn://foo.com#foo Best, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am Sun, 18 Apr 2010 20:49:37 +0200 schrieb Thomas Keller m...@thomaskeller.biz: Secondly, I'd actively deprecate any branch name which does not match the following regular expression, i.e. by throwing a warning when a branch cert which a different value is created: ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ Sounds good to me, but maybe we have to ask our users, whether that'd be ok for them. And we should still allow them to use other branch names if they wish so (because technically, there's no need for such a restriction). mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$' shows only one branch that doesn't match in my local copy of the monotone db (prjek.net:tester). -Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am Wed, 28 Apr 2010 02:50:09 -0400 schrieb hend...@topoi.pooq.com: On Wed, Apr 28, 2010 at 12:36:59PM +0200, Thomas Moschny wrote: Am Sun, 18 Apr 2010 20:49:37 +0200 schrieb Thomas Keller m...@thomaskeller.biz: Secondly, I'd actively deprecate any branch name which does not match the following regular expression, i.e. by throwing a warning when a branch cert which a different value is created: ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ Sounds good to me, but maybe we have to ask our users, whether that'd be ok for them. And we should still allow them to use other branch names if they wish so (because technically, there's no need for such a restriction). mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$' shows only one branch that doesn't match in my local copy of the monotone db (prjek.net:tester). And what would you do with that branch if this were to become a restriction? I said I'd agree with the idea of *warning* the user (not *disallowing* usage of such branch names), I also said I think there's no technical need to restrict branch names - besides obvious things like \0, and given there's a way to quote characters if necessary (e.g. using URL quoting). - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone-viz and repository structure.
Am Tue, 23 Feb 2010 09:02:16 -0700 schrieb Derek Scherger de...@echologic.com: On Tue, Feb 23, 2010 at 1:48 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: hend...@topoi.pooq.com writes: Right; you can pull any branch into any repository (= monotone database). But then you do have to be careful not to accidentally send a branch to an upstream repository; we don't want to have non-monotone branches in the database at monotone.ca. Except that we do... and the access rules seem to prevent one from getting them. Yes, and that seems to be because Richard (who is kindly hosting the monotone repository) has some 'private' branches in there, or maybe he is using usher. But Stephe is right in that if somebody else wants to have some branch hosted on monotone.ca, he should ask first, and it should be at least remotely connected to monotone. phew... that was fun. Interestingly we apparently do have a mechanism for finding out what branches exist on a server, tedious though it may be. Not sure if that itself could already be classified as a 'leak'. On the other hand it would be possible to use mtn au remote ls branches, iff monotone.ca was running 0.46 and your key was allowed to execute automate commands there. Regards Thomas -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone-viz and repository structure.
Hi Hendrik, Am Sun, 21 Feb 2010 15:57:57 -0500 schrieb hend...@topoi.pooq.com: On Sun, Feb 21, 2010 at 03:35:42PM -0500, hend...@topoi.pooq.com wrote: I have my own copy of the monotone repository. At least I think I do. It seems to sync properly when I pull. But I' trying to obtain monotone-viz. It doesn't seem to be in my repository, Is this just an accident of history, that I failed to specify the branch when I pulled monotone initially? Or is it, and should it be, in a completely separate repository? It is in the branch net.venge.monotone-viz (and some subbranches thereof) in the monotone repository served at monotone.ca. Depending on the pattern you are using (see mtn ls vars database) this branch name might have never matched during pull for you. Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Issue With remote_stdio
Hi! Am Sat, 13 Feb 2010 10:15:43 + schrieb Anthony Edward Cooper aecoo...@coosoft.plus.com: Just tried out the new mtn au remote_stdio and it insists on a local database (ran command outside of a workspace). Presumably a bug, anyone reported/fixed this already? That's known albeit not in the ticket system yet. Care to open a bug? Meanwhile you can use -d :memory: as a workaround. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am Thu, 14 Jan 2010 09:43:18 +0100 schrieb Thomas Keller m...@thomaskeller.biz: We also got recently a notification that 0.45 (and likely also 0.46) won't compile on gcc-4.5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565083 I don't know the release schedule of gcc, but maybe we could fix this one specific issue before 0.46 is out, because I doubt we have another release out in a month or so, so 0.46 will be around for a while. As far as Fedora is concerned, gcc 4.5 will not be in F13, and F14 could be released in November, so there's some time left. Anyway, the fix was easy, it was a missing #include roster.hh in selectors.cc, committed in 743110f6dc3d8b3dd2b975eb4dec13f1e2e47c09. Btw, while checking this in a debian chroot, I saw the netsync_largish_file test failing: [...] mtn: peer localhost:59751 IO terminated connection in working state (error) mtn: error: I/O failure while talking to peer localhost:59751, disconnecting [...] mtn: peer 127.0.0.1:41314 IO failed in working state (error) mtn: operation canceled: Terminated [...] Is anyone else able to reproduce this, or has any clue what's going on there? -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
J Decker wrote: Nice, works pretty well. I do miss the More/Less revisions on the graph feature, however... Used to be able to show the past to see a tangled mess of branches +/- 2 revisions from the current' isn't always a good enough picture. Was this ever a feature of ViewMTN? Guess I need to dig through the code a bit... - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Ludovic Brenta wrote: I could create it all right (http://viewmtn.1erlei.de/ticket/1) but I cannot see it; the URL contains only the error message: Unsupported version control system svn: Can't find an appropriate component, maybe the corresponding plugin was not enabled? Hm, yeah, this Trac instance wasn't properly configured. The ticket is visible now. Thanks! PS. This is the first time I create a bug report with number 1 :) - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Hi! Just to let you know, that the new home of ViewMTN is here: http://viewmtn.1erlei.de/ . There's also a live ViewMTN instance at http://mtn-view.1erlei.de/ carrying the nvm* branches as well as some random other branches that are mtn-related. Feel free to send me comments or hints regarding ViewMTN or the website, or if you like to see some other branches served there. Note that the new home of the project is in fact a Trac instance, so the preferred way of communicating is to open a ticket there. Btw, if someone here has graphic artist skills... a good idea for a logo is more than welcome ;) Regards, Thomas I wrote: Hi Grahame, Grahame Bowland wrote: It's over a year since I did much on ViewMTN. I'm not interested in continuing to work on the project, so I'm looking for someone to take over maintainership. If anyone puts their hand up I am more than happy to help with any questions or problems. Thanks in advance to anyone that puts their hand up! First of all thanks for developing that useful front-end! If no one else want to take over maintainership, I could step in - maintaining your package in Fedora anyway on the one hand, and having some Python code interfacing Monotone on the other hand. Maybe we can discuss details off-list. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Ludovic Brenta wrote: I reported a bug here in March. I'd like to open a ticket but cannot log in and I didn't find out how to create a new user account for me Thanks for the hint. You should now be able to create a ticket without having an account. (Hopefully the spam filter works reasonably well ;) - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
Am 23.08.2009 14:20, schrieb Stephen Leake:
The mtn binary for Linux on the mtn website should be more fully
described (compiler version, required dynamic library versions), so
people can do the right thing with it.
What is the right thing besides downloading, unpacking, running?
Also, it describes itself pretty good:
$ ./mtn-0.44-linux-x86 version --full
monotone 0.44 (base revision: 7a4832143b3146ca89f5cb91e0e571d05e29d4b9)
Running on : Linux 2.6.29.6-217.2.8.fc11.i586 #1 SMP Sat Aug 15
00:44:39 EDT 2009 i686
C++ compiler: GNU C++ version 4.3.2
C++ standard library: GNU libstdc++ version 20080905
Boost version : 1_34_1
SQLite version : 3.5.9 (compiled against 3.5.9)
Lua version : Lua 5.1
PCRE version: 7.6 2008-01-28 (compiled against 7.6)
Botan version : 1.7.8 (compiled against 1.7.8)
[...]
It is a binary for ia32 Linux that only needs glibc 2.3 (and most likely
also runs on 64bit Linux, given it provides a 32bit glibc):
$ ldd ./mtn-0.44-linux-x86
linux-gate.so.1 = (0x00e75000)
libdl.so.2 = /lib/libdl.so.2 (0x0048)
libm.so.6 = /lib/libm.so.6 (0x00456000)
libpthread.so.0 = /lib/libpthread.so.0 (0x00487000)
libc.so.6 = /lib/libc.so.6 (0x002e3000)
/lib/ld-linux.so.2 (0x002bf000)
$ readelf -s ./mtn-0.44-linux-x86 |
sed -r '/GLIBC/{s,^.*@(GLIBC_[0-9.]+).*$,\1,;n};d' | sort -u
GLIBC_2.0
GLIBC_2.1
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.4
GLIBC_2.3
What exactly would you suggest writing on the website?
Regards,
Thomas
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn and superuser on Fedora 11
Nicolas Ruiz wrote: Zack Weinberg wrote: This is a known bug in the Botan cryptography library that we use. I don't know exactly which version fixed the bug, but it *has* been fixed; try to get a newer version of libbotan. fedora uses libbotan 1.8.2 while debian unstable is using 1.8.5. I will try what you suggest. Thanks. Recently I have updated botan for Fedora to 1.8.6. The package is currently in updates-testing. Try yum --enablerepo=updates-testing install botan - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] building monotone on Red Hat Enterprise 4
Stephen Leake wrote: I'm trying to build monotone head on Red Hat Enterprise 4. gcc is gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) Botan, Lua, pcre get past the mtn configure checks, but sqlite does not: [... undefined references ...] Do these errors look familiar? Maybe I need a newer pthread library? Reminds me more of problems with the order of libraries in the final link step I saw when building the (semi-) static binary we have on the website. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Hi Grahame, Grahame Bowland wrote: It's over a year since I did much on ViewMTN. I'm not interested in continuing to work on the project, so I'm looking for someone to take over maintainership. If anyone puts their hand up I am more than happy to help with any questions or problems. Thanks in advance to anyone that puts their hand up! First of all thanks for developing that useful front-end! If no one else want to take over maintainership, I could step in - maintaining your package in Fedora anyway on the one hand, and having some Python code interfacing Monotone on the other hand. Maybe we can discuss details off-list. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] building monotone on Red Hat Enterprise 4
Stephen Leake wrote: Thomas Moschny thomas.mosc...@gmx.de writes: Reminds me more of problems with the order of libraries in the final link step That makes sense. I added -ldl and the dlclose etc references got resolved. Any hint which library has the pthread symbols? You need -pthread, in the compile as well as in the link step(s) - note that it is not -lpthread, but simply -pthread, no typo. Look through the ml archive, there's a thread about that issue some time ago. Basically, if one of the libraries we use is compiled with pthread support, we should add -pthread everywhere. (I consider it an error that neither pkg-config --cflags sqlite3 nor pkg-config --libs sqlite3 output -pthread, but yeah, some people seem to disagree.) I saw when building the (semi-) static binary we have on the website. Which one is that? http://monotone.ca/downloads/0.44/mtn-0.44-linux-x86.bz2 This is not an archive, but a single, compressed binary, with no other dependencies than that provided by glibc 2.3. It would be good to describe the library dependencies of the distributions. Not sure I understand what you mean here. It would also be good to include the specific build instructions in some file in monotone, so others can reproduce it. Build instructions for what? The static binary? That is currently built by hand, as I wasn't in the mood working through our auto*tools stuff yet to implement that. The Windows native installer includes the necessary DLLs, and build instructions are in monotone/INSTALL and monotone/win32/README. No need to separately ship libraries for Linux, see above. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn log now converts dates to the user's timezone
Zack Weinberg wrote: At present, the only thing affected is 'log'. My immediate thought is that absolutely we should *not* apply these changes to the automate interface, because that's intended for machine consumption; in particular, you don't want to have to parse whatever arbitrary gunk the user put in their date format spec. Exactly what I thought. Converting dates to some locale is something a presentation layer should do. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn log now converts dates to the user's timezone
Zack Weinberg wrote: On Fri, May 29, 2009 at 12:39 PM, Thomas Moschny thomas.mosc...@gmx.de wrote: Zack Weinberg wrote: At present, the only thing affected is 'log'. My immediate thought is that absolutely we should *not* apply these changes to the automate interface, because that's intended for machine consumption; in particular, you don't want to have to parse whatever arbitrary gunk the user put in their date format spec. Exactly what I thought. Converting dates to some locale is something a presentation layer should do. I could argue, though, that back-converting from the textual UTC date format that monotone prints to a system time_t that can be handed to localtime() is a huge pain, and monotone already *has* that code... Well, that's something different. It might indeed be easier for the consumer to deal with a system_t (i.e. seconds since unix epoch) than to parse the textual date format. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] automate get_current_revision failing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! In f62181ae.. someone made mtn automate get_current_revision fail in case the workspace is clean, and the revision is trivial (empty changeset). I don't see why this should fail, and furthermore, it breaks the logic that makes mtn revision --full display changes made against the base revision. So, I'd like to partially revert that (see patched attached). Any objections? - - Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmxsbcACgkQm/6MhNYca5jodgCggs5JkIahd2/C66oLXC/d5QgA sDoAn32ZHxIB2swDfYHeUFEx7iGshamO =zV9Z -END PGP SIGNATURE- # # old_revision [d24b59732a5b3293592457cba013c8f8b716a875] # # patch automate.cc # from [63b44f3c2366f52a040cc8d0029ffc1d896740d9] #to [4a5ef4b00f72c0c766b65bcf4d26fce3c662cbfc] # # patch monotone.texi # from [50c10e49ae961d0b36374f02b09b5af2fab9cb00] #to [d562dab57e07e0822e54af0b40dea69881c085c5] # # patch tests/automate_get_current_revision/__driver__.lua # from [a56d2598ca7be71521f38b0a577baa92fbf55022] #to [febb7bc6adea00e46e2f0e932ec3f939badab4a2] # --- automate.cc 63b44f3c2366f52a040cc8d0029ffc1d896740d9 +++ automate.cc 4a5ef4b00f72c0c766b65bcf4d26fce3c662cbfc @@ -1260,8 +1260,7 @@ CMD_AUTOMATE(get_revision, N_(REVID), // Added in: 7.0 // Purpose: Outputs (an optionally restricted) revision based on // changes in the current workspace -// Error conditions: If there are no changes in the current workspace or the -// restriction is invalid or has no recorded changes, prints an error message +// Error conditions: If the restriction is invalid, prints an error message // to stderr and exits with status 1. A workspace is required. CMD_AUTOMATE(get_current_revision, N_([PATHS ...]), N_(Shows change information for a workspace), @@ -1293,7 +1292,6 @@ CMD_AUTOMATE(get_current_revision, N_([ make_restricted_revision(old_rosters, new_roster, mask, rev, excluded, join_words(execid)); rev.check_sane(); - E(rev.is_nontrivial(), origin::user, F(no changes to commit)); calculate_ident(rev, ident); write_revision(rev, dat); --- monotone.texi 50c10e49ae961d0b36374f02b09b5af2fab9cb00 +++ monotone.texi d562dab57e07e0822e54af0b40dea69881c085c5 @@ -7716,9 +7716,8 @@ @section Automation @item Error conditions: -If the command is executed outside of a workspace, there are no changes in the -current workspace or the restriction is invalid or has no recorded changes, -prints an error message to stderr and exits with status 1. +If the command is executed outside of a workspace, or the restriction is +invalid, prints an error message to stderr and exits with status 1. @end table --- tests/automate_get_current_revision/__driver__.lua a56d2598ca7be71521f38b0a577baa92fbf55022 +++ tests/automate_get_current_revision/__driver__.lua febb7bc6adea00e46e2f0e932ec3f939badab4a2 @@ -6,8 +6,7 @@ check(mtn(commit, --date=2005-05-21T1 --branch=testbranch, --message=blah-blah), 0, false, false) -- ensure clear workspace fails wih error -check(mtn(automate, get_current_revision), 1, true, false) -check(fsize(stdout) == 0) +check(mtn(automate, get_current_revision), 0, true, false) addfile(foox, blah\n) addfile(barx, blah2\n) get_current_revision.patch.sig Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] gcc warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zack Weinberg wrote: These are a harmless false positive (it's a subclass-to-base conversion but gcc 4.3 doesn't know that when the warning issues, because it's only got a forward declaration of the subclass). With gcc44, some more warnings about breaking strict-aliasing rules show up (duplicates not listed): commands.cc: In function 'commands::command_id commands::complete_command(const args_vector)': commands.cc:427: warning: dereferencing type-punned pointer will break strict-aliasing rules commands.cc:437: warning: dereferencing type-punned pointer will break strict-aliasing rules hybrid_map.hh: In member function 'virtual void commands::cmd_revert::exec(app_state, const commands::command_id, const args_vector) const': hybrid_map.hh:167: warning: dereferencing pointer 'anonymous' does break strict-aliasing rules hybrid_map.hh:167: note: initialized from here migrate_ancestry.cc: In member function 'voidunnamed::anc_graph::fixup_node_identities(const parent_roster_map, roster_t, const legacy::rename migrate_ancestry.cc:553: warning: dereferencing pointer 'anonymous' does break strict-aliasing rules /usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:259: note: initialized from here - - Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmuunwACgkQm/6MhNYca5jz2QCfV+NMuteiX0dWTvZsS9UBMBxK eCkAniPwKSnRJBnHsDqwOKm51e/tYVBm =kZ+y -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] gcc warnings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zack Weinberg wrote:
On Wed, Mar 4, 2009 at 10:17 AM, Zack Weinberg za...@panix.com wrote:
I don't have gcc4.4 to hand, but do you get the same diagnostic with
this test case?
Slight correction:
#include map
typedef std::mapunsigned int, unsigned long M;
bool test(M m, unsigned int k, unsigned long v)
bool test(M const m, unsigned int k, unsigned long v)
{
M::const_iterator i = m.find(k);
if (i == m.end()) return false;
return (i-second == v);
}
No warning with that test case.
- - Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmuyG8ACgkQm/6MhNYca5ik6gCfS1pq3PEHzLfWMM6MKxY+08Hd
3J8AniRh8aHWz+S/PEYq4W7vl12p59nY
=fWWa
-END PGP SIGNATURE-
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] gcc warnings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zack Weinberg wrote:
On Wed, Mar 4, 2009 at 10:29 AM, Thomas Moschny thomas.mosc...@gmx.de wrote:
Zack Weinberg wrote:
I don't have gcc4.4 to hand, but do you get the same diagnostic with
this test case?
#include map
typedef std::mapunsigned int, unsigned long M;
bool test(M const m, unsigned int k, unsigned long v)
{
M::const_iterator i = m.find(k);
if (i == m.end()) return false;
return (i-second == v);
}
No warning with that test case.
What compiler flags did you use? You need at least -O2 -Wall I think...
- -Wall -W -O2 -g
- - Thomas
PS: For the record - note that this is with a gcc rpm from fedora devel,
not a released one.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmuzL0ACgkQm/6MhNYca5j8UgCeNgSZyPzE8EfO0zXaD2hWhalO
IgwAnA5wTW2NuP2N4b6wDf96+Zs5WWLt
=uLKv
-END PGP SIGNATURE-
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] update clearing execute permissions [was re:git fast-export]
Derek Scherger wrote: I've committed a fix on net.venge.monotone for this problem in b1cec3176fd56af29275c2b620f8766b4382eec8 which fixes two associated xfailed tests in the monotone testsuite (tests/attr_mtn_execute and tests/defecting_attriibutes). Great! Had something similar, but not yet working, in my workspace for a while. I factored out the code to set/get the x bit in f954b59c88.. . One question though: in editable_working_tree::clear_attr(), you call lua.hook_apply_attribute with an empty string for 'value'. So, while this doesn't lead to wrong behavior in the case of mtn:executable, I think that's not correct in general. We should distinguish between the two cases where some attribute has been or is set with any value (even with an empty value), and where it is not set at all. So in short, I think we should pass NIL to the lua hook when an attribute is cleared, instead of , because the latter could be a valid value. It would be good to get some eyes on this change from people who understand the monotone internals. For those people, this change mainly affects the update and pluck commands and the stuff I'm marginally worried about is the make_revision_for_workspace and resolve_merge_conflicts calls because the merged roster may have some dormant attributes on it that previously were not there. From what I can tell, a cset between a roster with no foo attr and one with a dormant foo attr is empty but if it wasn't this change might cause some problems. As far as I know the revision (i.e. changeset) format doesn't have the vocabulary to talk about dormant attributes, and imho it shouldn't need to. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.42: peer [...] IO failed in confirmed state (success)?
Adam Panayis wrote:
Hi, I have the same problem as described here:
http://www.mail-archive.com/monotone-devel@nongnu.org/msg12494.html
Is there way to get the revised code before the next full release of
monotone?
You could try the attached patch, it should fix the problem. It is
rediffed version of Markus' patch in revision f18abebd.. on mainline.
- Thomas
diff -up monotone-0.42/netsync.cc.orig monotone-0.42/netsync.cc
--- monotone-0.42/netsync.cc.orig 2009-02-04 13:53:00.0 +0100
+++ monotone-0.42/netsync.cc 2009-02-04 13:53:49.0 +0100
@@ -353,7 +353,7 @@ unsigned int reactable::count = 0;
class session_base : public reactable
{
- bool read_some();
+ void read_some(bool failed, bool eof);
bool write_some();
void mark_recent_io()
{
@@ -468,10 +468,12 @@ session_base::which_events()
return ret;
}
-bool
-session_base::read_some()
+void
+session_base::read_some(bool failed, bool eof)
{
I(inbuf.size() constants::netcmd_maxsz);
+ eof = false;
+ failed = false;
char tmp[constants::bufsz];
Netxx::signed_size_type count = str-read(tmp, sizeof(tmp));
if (count 0)
@@ -479,17 +481,38 @@ session_base::read_some()
L(FL(read %d bytes from fd %d (peer %s))
% count % str-get_socketfd() % peer_id);
if (encountered_error)
-{
- L(FL(in error unwind mode, so throwing them into the bit bucket));
- return true;
-}
+L(FL(in error unwind mode, so throwing them into the bit bucket));
+
inbuf.append(tmp,count);
mark_recent_io();
note_bytes_in(count);
- return true;
+}
+ else if (count == 0)
+{
+ // Returning 0 bytes after select() marks the file descriptor as
+ // ready for reading signifies EOF.
+
+ switch (protocol_state)
+{
+case working_state:
+ P(F(peer %s IO terminated connection in working state (error))
+% peer_id);
+ break;
+
+case shutdown_state:
+ P(F(peer %s IO terminated connection in shutdown state
+ (possibly client misreported error))
+% peer_id);
+ break;
+
+case confirmed_state:
+ break;
+}
+
+ eof = true;
}
else
-return false;
+failed = true;
}
bool
@@ -531,11 +554,14 @@ bool
session_base::do_io(Netxx::Probe::ready_type what)
{
bool ok = true;
+ bool eof = false;
try
{
if (what Netxx::Probe::ready_read)
{
- if (!read_some())
+ bool failed;
+ read_some(failed, eof);
+ if (failed)
ok = false;
}
if (what Netxx::Probe::ready_write)
@@ -578,7 +604,11 @@ session_base::do_io(Netxx::Probe::ready_
% peer_id);
ok = false;
}
- return ok;
+
+ // Return false in case we reached EOF, so as to prevent further calls
+ // to select()s on this stream, as recommended by the select_tut man
+ // page.
+ return ok !eof;
}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.asio
Zack Weinberg wrote: [...] right now the only thing I've done on it is bump the Boost version requirement to 1.35, which lets us get rid of the boost/ directory in the source tree (they finally incorporated the circular_buffer classes into the official distribution). They don't seem to have broken anything we use going from 1.34 to 1.35. In general, I very much appreciate the whole effort of getting rid of all the 3rd party stuff we carry around. I wonder though, whether we are going to loose the ability to build on older/long term support distributions. For example, RHEL5 has pcre 6.6, and (through the EPEL add-on repository) boost 1.33.1. So, building monotone 0.43 for EPEL will cause some headache, I fear (and the same might hold for other lts or server distributions). - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Zack Weinberg wrote: On Tue, Jan 20, 2009 at 4:16 PM, Jack Lloyd ll...@randombit.net wrote: That said, it's no good to slow mtn startup down so much since that is clearly not the Right Thing either. Do you think we could get away with skipping es_unix if we have something else, though? That's the really slow one. Indeed using --disable-modules=unix_procs while configuring botan makes a huge difference for monotone's startup time. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped versus botan
Zack Weinberg wrote: Also, do we really need cryptographic entropy in mkstemp.cc? Currently *every invocation* of monotone_mkstemp is initializing a new RNG object. Fortunately it's only called from LUAEXT(mkstemp), but still... Why can't we simply re-use the RNG object? Really, I don't think we should implement another pseudo random number generator ourselves. Basically it won't ever be properly reviewed. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Zack Weinberg wrote: I'd prefer not to drop the minimum version below the most recent point at which an exploitable crasher bug was fixed, which (according to pcre's NEWS file) was 7.6. There probably isn't an attack vector with our usage but I can't prove it so I'd rather be safe. (Can you find out if FC9 backported those fixes?) The pcre package in F9 has a backported fix for CVE-2008-0674, and also a fix for the more recent CVE-2008-2371 problem. - Thomas ___ 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
(Derek: sorry for resending, forgot to cc the list.) 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. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner wrote: Fedora 9 doesn't ship botan, either. I compiled from source, through the project website you can also find RPMs for botan. A Fedora botan package is on the way, see https://bugzilla.redhat.com/show_bug.cgi?id=480528. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] wiki
Hi Markus, Markus Wanner wrote: ugh.. am I working on the wrong branch for editing the wiki (net.venge.monotone.web.ikiwiki)? Beware - the nvm.web.ikiwiki branch has been merged back to nvm.web and suspended. Could you please propagate your last change(s) and suspend the branch again? How do I compile and test the wiki locally? Where's the documentation for it? This is explained in wiki/ikiwiki_migration.mdwn (rendered version here: http://monotone.ca/wiki/ikiwiki_migration/). Isn't the purpose of a wiki to be simple to edit and easy to search through? Sorry, but I currently miss both functions. But maybe I'm just looking at the wrong places... please help! Well, the migration to ikiwiki has been started on the last summit. The wiki being part of our Monotone database seems to be a great advantage compared to the old system. Also, ikiwiki's way of rendering the page contents only once, when the source has been changed, sounds like a good idea to me. Eventually we'll have a CGI-based mechanism for editing (and committing to) the wiki, if that's what you are missing. But before installing that that we need to be sure that we can prevent any spamming. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] git fast-export
Patrick Georgi wrote: Am Dienstag, den 06.01.2009, 09:47 +0100 schrieb Markus Wanner: This is a bit off-topic here, but: is there a use case for revisions without *any* branch cert? I think you get these if you pull a branch, which descends into other branches that you don't pull Yes, or later, when you don't trust a branch cert for some reasons. This is a general topic that has to be discussed in the scope of the so called policy branches: is it really meaningful to use a revision's data (in the sense that it is an ancestor of a revision I actively use or even commit myself), but not trust its metadata? But back to the topic: I wonder how missing or untrusted branch certs affect the git-export, unless these revisions are leaves? - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Replying to myself: Markus Wanner wrote: Daniel Black wrote: As per https://bugs.gentoo.org/show_bug.cgi?id=238540 monotone fails to compile when glibc is compiled with --disable-nls. This occures even when monotone is configured with ./configure --disable-nls. Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. fwiw, I can see the same compile problem when configuring monotone with --disable-nls on (standard) debian lenny and fedora 10. It turns out that this can be solved by updating our copy of gettext.h with a more recent version. If no one objects, I'm going to commit that. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Replying to myself: Markus Wanner wrote: Daniel Black wrote: As per https://bugs.gentoo.org/show_bug.cgi?id=238540 monotone fails to compile when glibc is compiled with --disable-nls. This occures even when monotone is configured with ./configure --disable-nls. Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. fwiw, I can see the same compile problem when configuring monotone with --disable-nls on (standard) debian lenny and fedora 10. It turns out that this can be solved by updating our copy of gettext.h with a more recent version. If no one objects, I'm going to commit that. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] git fast-export
Derek Scherger: I've spent a bit of holiday hacking time working on a git_export command for monotone, more as an experiment than anything else. Nice! This successfully (I think) converts the entire monotone database with 276 branches (more or less what you get when you pull '*' from monotone.ca http://monotone.ca) to a git repository.Here's some details on the conversion: This doesn't honor suspend certs, does it? And one more interesting question, what do you do with branches that have multiple heads? - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Markus Wanner wrote: Daniel Black wrote: As per https://bugs.gentoo.org/show_bug.cgi?id=238540 monotone fails to compile when glibc is compiled with --disable-nls. This occures even when monotone is configured with ./configure --disable-nls. Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. fwiw, I can see the same compile problem when configuring monotone with --disable-nls on (standard) debian lenny and fedora 10. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: exec flag not always set (Was: Re: [Monotone-devel] checkout automate?)
Felipe Contreras wrote: On Sat, Dec 20, 2008 at 10:14 AM, Hugo Cornelis hugo.corne...@gmail.com wrote: On Fri, Dec 19, 2008 at 5:39 PM, Felipe Contreras felipe.contre...@gmail.com wrote: I have some scripts that convert a mtn repo to git repo (as you might know) but I stumbled upon some issues while doing 'mtn update' (the exec flag is not properly set sometimes), so now I'm using 'mtn I have seen this to a couple of times, but I don't know how to reproduce it. Especially annoying when this breaks automated tests. Does anyone have an idea what the problem is, and is there a solution or workaround ? There are two problems: - As it seems to me, we are not calling lua hooks in case file attributes should be cleared on update. - We don't have lua code (that could be called from such a hook) to clear the execute permission bit, we only have code to set it. The second problem is easy to solve, and in fact I have already code for that, but currently I don't have time to look at the first issue, will come back to that after christmas. For now, I've added an xfailing test. AFAIK the Pidgin guys where able to reproduce this issue and even found a workaround. Would be nice to see how they did that. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] interface versions, again
Thomas Keller wrote: So, to make a long story short I propose that interface versions are _not_ changed by individual developers up until the next release and that the release manager rather takes care of the numbering, just because he gets the ultimative overview what has been added / changed when he writes the NEWS file. You gave good arguments why this is the only viable way. On the other hand, there's a downside: People using automate against a devel version (e.g. for testing the newly implemented features) will see wrong (i.e. too low) interface version. This dilemma is imho inherent to the numerical schema we currently use. I think I've proposed that before, but what would solve the issue is a keyword based interface version. So, instead of one numerical value, the interface version call would return a list of keywords, each of them specifying an sub functionality of the automate protocol, implemented by that server. This way new or changed functionality can be advertised immediately and independently of other parts of the protocol. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Thomas Keller wrote: The other (lazy) way would be to define a list of external libraries with which we know the build works (i.e. because we've tested them) and leave everything else to the downstream packagers. We receive bug reports and incorporate their fixes for the next release. This just became a rather small open source project, I don't think people have ressources to additionally check if monotone builds and behaves correct with all seven boost versions, three botans, two luas and whatever. Totally agree. Are we (when combining different versions of the used libraries) to expect subtle bugs that eat peoples databases with no one noticing? I guess most problems will rather arise at compile time or when running the test suite. And distributions should run the test suite before shipping their builds to the end user. For the Fedora package we surely do that. So, I'm in favor of merging this branch earlier rather than later, so maybe very soon after releasing 0.42. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Philipp Gröschler: As for the topics which I posted a few days ago, yes I would do some work on these topics if only I had a glimpse on C++ ;-) This is also the reason for which I didn't attend the Wuppertal summit this summer. I announced some kind of Java project on the mailing list and got a few messages on that, but no further responses on application. Concerning all other topics around C++ and Lua, I don't think I can be of any constructive help, unfortunately. You could enhance/revive/polish/hack on the eclipse monotone plugin, if you like. Regards, Thomas ___ 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
Stephen Leake wrote: Markus Wanner [EMAIL PROTECTED] writes: I'm just proposing to check the date and warn the user if it obviously doesn't match. It would help making that meta-information more reliable, nothing more, nothing less. If there is no global shared clock, then developers working in different time zones can easily commit revisions to a shared server that have timestamps using local times that appear to be out of order with respect to each other. Monotone stores timestamps in the date certs in UTC, of course. Nevertheless, clocks for each developer might differ a bit such that commits appear to be made in non-chronological order. Why would you want to warn about that? So, I don't think we should warn there. - Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg wrote: On Mon, Sep 1, 2008 at 12:10 AM, Richard Levitte [EMAIL PROTECTED] wrote: Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? Possibly just needs putting util/mtnopt in EXTRA_DIST or whatever it's actually called then? Already fixed 'make distcheck' by moving mtnopt from bin_SCRIPTS to dist_bin_SCRIPTS, adding it to DISTCLEANFILES, and patching it to support '-- help' and '--version' ;) - Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Monday 01 September 2008 Thomas Keller wrote: Stephen Leake schrieb: I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? It should, or at least I would be surprised if it didn't. Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. Do all tests pass? I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. So if we can postpone a release until next weekend, I'd appreciate it. While a review could be done in a week, I'm not sure we should really be in a hurry. We can easily have a 0.42 in a month or so. On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. Yes, I also think that a cmdline interface for recording resolving decisions is needed. Not everyone is using emacs. At least the format of MTN/conflicts must be documented properly. Also, test cases are needed. (Maybe this is already done, didn't find the time yet to have a look at that branch). However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... Other opinions? Not meaning to discourage you, Stephen, but at this time, and with Thomas wearing the release manager cap already, I'd say, we'd better have 0.41 done now, and have your work merged in afterward. Having a 0.42 release within short time then would be fine and fully justified even by a single new feature. But of course the decision is up to Thomas as he's doing the work ;) - Thomas 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] can you please help to compile?
On Friday 11 July 2008 Zack Weinberg wrote: On Thu, Jul 10, 2008 at 1:45 PM, R K AVATAPALLI [EMAIL PROTECTED] wrote: i am trying to install monotone 'monotone-0.40' from 'monotone-0.40.tar.gz' i already installed 'boost_1_35_0' from boost_1_35_0.tar.bz2' i am using Fedora Core 4 linux operating system. [...] tell me that you are using an old, buggy C++ compiler, and this is almost certainly the source of the problem. Your options are: * Upgrade your operating system. * Upgrade just the compiler using packages from Fedora. * Download a recent version of GCC and compile it yourself. This is not difficult. * Don't bother compiling monotone yourself and use the pre-compiled binary available here: http://monotone.ca/downloads/0.40/mtn-0.40-linux-x86.bz2. This is a stand-alone binary, simply download, bunzip2, and put it in a directory on your path, like /usr/local/bin. - Thomas 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] Blank spaces in monotone manual?
[EMAIL PROTECTED]: While reading http://www.monotone.ca/monotone.pdf using konqueror I've noticed mysterious blank spaces in the manual. Specifically, in section 1.7 Branches after the words Branches tell monotone which revisions you would like to merge, and which you would like to keep separate. there is a blank space about the same siza as this paragraph, followed by the words You can see all the available branches using mtn list branches, followed by another blank space. Is this a problem with my browser, or are there really blank spaces in the manual, possibly pending further revision? The blank spaces are a result of TeX's typesetting process having problems when the ratio between size occupied by images and amount of text on a page is bad (i.e. a lot of non-tiny images). Here, the generated PDF looks better, after I scaled down one image a bit, see b507bcb3.. - Thomas 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] ikiwiki
Thomas Keller wrote: Furthermore we should also look later on on those pages which have not yet been converted if they're worth of being converted at all (things like new pages which contain just one implementation idea might be moved somewhere else, for example). I've converted all remaining moin files. There are some formatting issues left, but those can be solved later (and some pages can probably be deleted, yes.) All pages are now tagged either 'done', 'wip', or 'auto'. 'wip' however, despite it's name doesn't seem to mean that someone is in the middle of reworking that page, but merely that it is not considered done yet and probably needs a helping hand. So, everyone, pick some of those pages, bring them in shape (mostly content- wise, that is), and mark them as done! - Thomas 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] ikiwiki
On Thursday 19 June 2008, [EMAIL PROTECTED] wrote: If you're going to have a captcha ... I think it's the Univerity of Illinois library that provides a free captcha service. They're in toe pocess of digitizing their entire collection, and they use the words and phrases that their OCR systems fail on as a source of captchas. Apparently is's quite effective at weedind out bots, and not hard on real human beings. And it helps them digitize their library. I found it following links from googling (or wikipeding) CAPTCHA. Didn't keep the link. Do you mean http://recaptcha.net/ Not sure whether ikiwiki supports it, though. - Thomas 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 displays commit times in UTC, not local time
On Thursday 05 June 2008, Zack Weinberg wrote: On Thu, Jun 5, 2008 at 12:26 PM, Nuno Lucas [EMAIL PROTECTED] wrote: Or you could just use the sqlite date/time functions[1] to have it return localtime instead of UTC. The dates are not stored in a way that would make that possible. Really? % mtn db execute 'select value, datetime(value, localtime) from revision_certs where id=05dc2c12e723382d5c6ced4b7b9df9ed63f31bb8 and name=date' 2008-06-02T14:42:33 | 2008-06-02 16:42:33 Seems correct (CEST (UTC+2) in effect here now). Now take an older revision, say 61a83351.., yields: 2008-01-30T19:13:26 | 2008-01-30 20:13:26 In January, CET (UTC+1) was in effect here. - Thomas 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] resolving name conflicts; file suturing vs drop
On Saturday 10 May 2008 Derek Scherger wrote: Thomas Moschny wrote: *But*, I changed my mind, and now think that we must care about file identity relationships. What we really want, is this: Pretend we could go back and give both 'foo' nodes in A and B the very same node identity. The whole monotone merging machinery would work as expected. Initially I really liked this idea, even though it does seem a bit strange to go back and rewrite the old rosters, it does accomplish suturing. However, on the way home today, it occurred to me that actually doing this may not be the right thing because it doesn't record history as it happened but actually changes the history which we're trying to preserve. Sure. That's why I said 'pretend we could go back...'. It was merely a gedankenexperiment that can help us find out what the merging rules will look like, not a suggestion to really rewrite history. I'm back to thinking the right thing to do is to drop *both* old nodes and create a new one representing the suture, and to do whatever else we need to so that the new node somehow refers to both of its sources. Similarly, for splitting a file (i.e. un-suturing) I think we should drop the original single node id and create two new ones that both refer to their single source. For an asymmetric copy it seems reasonable to keep the source node and add a single new node representing the copy. So, all we need is some way for a node to refer to 0, 1 or 2 source nodes (2 for a suture, 1 for an asymmetric copies and splits and 0 for simple additions). Exactly. In another mail in this big thread I wrote that I think we should extent each nodes' birth records to contain 0-2 source nodes (specified in terms of paths in one of the parent revisions.) Then we need to work this through the merging machinery. Right, that's what we need to do now: Find out how to merge two nodes that have a somehow connected node identity. My guess is that there will be different rules for content, path and aliveness (besides the fact that we need to update aliveness merging rules themselves first). Regards, Thomas 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] resolving name conflicts; file suturing vs drop
Markus Schiltknecht wrote: And I'm currently concluding that the 'single bit aliveness flag per node id' is overly complex for us and for the end user, while suturing and copying might achieve pretty much the same effect. As I pointed out in another mail, it's not the bit that is complex - we already have that: a node can be present in a manifest or not, that's effectively the bit. What we do not have currently, is a cache of the corresponding markings. To be more precise: we don't have pointers to the (obviously marked) revisions in which a node died. Regards, Thomas 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] resolving name conflicts; file suturing vs drop
Markus Schiltknecht wrote: (graph kept for reference) Thomas Moschny wrote: A: 1,foo,v B: 2,foo,w /\ /\ / \/ \ |\__/\ | / C: 12,foo,x | /\ |/ \ | D: 2,bar,y \ |__/ | E: 1,foo,v| \ 2,bar,y| \___| F: ??? [...] Now, consider F, merging E and C. How does its manifest look like? Well, there's no way you can merge two revisions with an ncc, so there cannot be such a manifest in the first place. There can, that's what suturing is about. It is the same thing happening in C, where we are suturing 1 and 2 both wanting 'foo' into 12. Why shouldn't that be possible again in F for 1 and 12 ? E C | G: - # rev G drops 3 (i.e. the sutured 12) here H: 4,foo,v/ \ 5,bar,y / # rev H saves nodes 1 and 2 by \ / # copying \ / F: 4,foo,v # a clean merge now. 1 and 2 are gone due 5,bar,y # to the suturing into 3, which got then got # dropped in G. You are cheating here. We don't have well defined nor understood semantics for copy yet. And by simply exchanging 3 for 12, or 4 for 1 and 5 for 2, you are pretty much hiding what we are (well, I am, at least) talking about: Establishing connections between different node identities. That is, a new node needs to able record the fact somewhere that it wants to inherit (or asymmetrically share) identity from (with) another node. I still have to think of what that actually means, though, especially for our merge algorithm, which certainly has to to be extended. What I'm thinking of (implementation wise) is extending the birth record to be able to contain a list of 'ancestor' nodes, in terms of node paths in the respective parent revision. Note (a) that we don't have node_ids there, so nodes must be referenced by name, and (b) that we certainly don't want to allow nodes to be referenced in other revisions than in its direct parents. Otherwise we would create a new graph that can not be embedded in our revision graph, and my intuition says that would be a very bad thing (tm). This would allow suturing and asymmetric copying, but not resurrection in the copy-sense, hopping over a whole part of the history. But that's fine anyway, because you can always commit a child revision of an old revision where the file in question was still alive and merge that with your current head, and that's the Monotone way of doing it. Regards, Thomas 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] resolving name conflicts; file suturing vs drop
Markus Schiltknecht wrote: William Uther wrote: This isn't totally correct. You need the node-id's you're talking about, but you also need the marks for mark-merge. As has been noted by Thomas in another email, the problem with resurrection isn't with finding the node-id, it is with being able to get the marks when you later do the merge. At the moment we don't keep the marks when we drop a file. With suturing + copying, as I'm envisioning, we don't need to keep them. Yes, we do need them, that's pretty much sure (or, at least, we need to reconstruct them on demand, as William suggests). They are needed for killing DieDieDie. You can always (without having resurrection in the extended, copy-like sense!) go back to an old revision, where the file was still alive, make a new child (changing the file maybe) and merge that with current head. Currently, this won't bring the file back, but it should. And for this to work, we need the markings. Note: This is a basic problem to be solved independently and probably not related at all to the discussion we are having here. Regards, Thomas 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] resolving name conflicts; file suturing vs drop
Patrick Georgi wrote:
Couldn't resurrection be done with a revision item like
It's not about how to encode the resurrection action, but about recording the
fact that a node is dead in a revision, and where it was killed. The latter
is the important thing. If you simply omit that information, then, if you
merge that revision with another revision that _has_ the node, you don't know
whether to keep it in the merged node or not. It could have been added or
resurrected on the one side and deleted or simply not yet be born on the
other side. We want to use our standard *-merge algorithm, which clearly
indicates whether the node is to keep or not, based on (i) the scalar value
('aliveness') on both sides and (ii) the markings for that scalar on both
sides. (i) is easy (node is there or not), but (ii) is what we have to care
about.
In general, we decided to cache markings for the interesting scalars (path,
content, and attribute changes as well as births) together with the actual
values (path, content, attributes) for each node of the revision graph. That
is what we call a roster. Again, it's a cache, and could completely be thrown
away and reconstructed from the changesets.
The death markings ((ii) from above) can also be easily reconstructed, but
this would impose a perfomance penalty. That's why we have to think about way
of also caching that information, be it as part of the roster, or as a
separate graveyard, or whatever.
[...]
but:
0 file a exists
/ \
1 3 file a is changed (differently in both 1 and 3)
2 4 file a is deleted (both in 2 and 4)
\ /
5
6 file a is resurrected
Which version should mtn resurrect? (it could ask the user, but we
don't do that for other non-content issues, so what would be the
default?)
This is the well-known problem of delayed content-conflicts arising on file
resurrection. It *is* a content-conflict, and must be propagated to the user.
In your example, there are only two changes conflicting, but you can easily
imagine a case with N conflicts having suddenly to be solved.
Regards,
Thomas
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] resolving name conflicts; file suturing vs drop
Markus Schiltknecht wrote: Thomas Moschny wrote: A B / \ /| | X | | / \| | C D |/ E Suppose A has add foo, B has add foo, D is a simple merge, so D contains a single sutured file name foo. Suppose also that C has rename foo bar, and E is a simple merge, so E has two files foo and bar. Now, I merge E and D. What happens? If D actually dropped both 'foo' nodes and created a new one 'foo' node with merged content, merging D and E would be a clean merge: drop 'foo' from A and drop 'bar' (being 'foo' from B), and add the new 'foo'. No conflict (with or without DieDieDie, in that example). Hm.. no, we cannot let drop merge cleanly with suturing. Agreed, but in the example, this is not the case anyway. The only thing I said was: *If* we implemented suturing as drop,drop,add (all within D), and not cared about the relationships between the newly created file and its predecessors, then there were no conflicts at all while merging D and E. *But*, I changed my mind, and now think that we must care about file identity relationships. What we really want, is this: Pretend we could go back and give both 'foo' nodes in A and B the very same node identity. The whole monotone merging machinery would work as expected. However, we simply can't do that. We can't go back and treat two different file identities as a single one. Well, we can do it, locally, but only *as soon as we know about the users wish to do so*. And the user in turn cares to tell us only when ncc conflicts arise. And that's the point with Nathaniel's example: D knows about the problem, but E does not, so in E we have two nodes, and a delayed (=not yet resolved) content conflict popping up when we merge D and E. In *that* case, there would be aliveness conflicts (and probably also a chain of content conflicts following) for old 'foo' and 'foo' aka 'bar' nodes, like Nathaniel described. Uh.. why does marking aliveness state influence the amount of content conflicts? But that probably shouldn't scare us anymore after we have learned how to control resurrection and the content conflict chains arising there. I've completely lost you here, sorry. Let me put it in other words: Killing DieDieDie and implementing suturing properly will both yield merges where we are confronted with a series with more than two content conflicts on the same file. Yeah, I'm aware of that problem. However, I don't think suturing (nor copying) has much to do with file resurrection. They do, see above. That's why I am still thinking we need a new storage scheme that allows easily access to relevant parts of a roster - as we already do for restricted log and annotate, but in a cleaner fashion. Hm.. you mean splitting the aliveness information from rosters, as we have split height information? Or what do you have in mind? No, no. Height information is also a cache, but at the level of revisions, and totally unrelated here. Rosters are caches carrying per-revision, per-node information (see my other post), but are currently accessible per-revision only. All I'm saying is that we should break this up and allow access to node-specific parts of a roster. Regards, Thomas 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] resolving name conflicts; file suturing vs drop
Markus Schiltknecht wrote: You might even have renames, so that the file to be resurrected isn't currently visible. How's the user supposed to resurrect the file then? Now I lost you ;) Resurrection is about bringing dead files back to live, so it will always be invisible before resurrecting it, no? Doesn't the user rather want to resurrect a file from a specific revision (possibly with a new target filename). That would make resurrection a simple copy, and we wouldn't need to carry on node ids forever. That he can do already, without need for implementing something: Simply use mtn cat and create a new file with old contents, poor mans copy. Works for deleted and non-deleted files. That's not what we are talking about. All three problems (resurrection, suturing, and copying) will need to establish some sort of connection between node identities in the graph (resurrection: 1-1, suturing: N-1, copying 1-N). We currently don't have (a) a mechanism to achieve that and (b) only a small clue of what problems will arise afterwards. Don't let us confuse and/or intermix these two steps. Regards, Thomas 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] resolving name conflicts; file suturing vs drop
Markus Schiltknecht wrote: Thomas Moschny wrote: However, we simply can't do that. We can't go back and treat two different file identities as a single one. Well, we can do it, locally, but only *as soon as we know about the users wish to do so*. And the user in turn cares to tell us only when ncc conflicts arise. And that's the point with Nathaniel's example: D knows about the problem, but E does not, so in E we have two nodes, and a delayed (=not yet resolved) content conflict popping up when we merge D and E. Correct. Anything wrong with that behaviour? No, nothing wrong. This is a case however, our ui currently can't handle, because when merging D and E, possibly two conflicts have to be solved for the same file, because we have three versions to be merged into one. I've been concentrating on suturing, here. That one must conflict with drop and rename. Agreed. How do you expect to run into a series with more than two content conflicts on the same file given only suturing as an additional feature? Well, that was what njs' example was all about, and what I tried to explain (again) above. When merging D and E, you we have to suddenly merge three versions of the same file. This is what I call a series with more than two content conflicts on the same file. You were still assuming nodes could change their aliveness state on one branch and be sutured on another branch and still merge cleanly. No, I don't. I already said that I consider it reasonable to mark the aliveness state when changing, renaming, or maybe suturing nodes. The effect of this is that dropping in another branch would conflict with these operations, and thus I think I agree with you on that point, but simply expressed it differently. - Thomas 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] resolving name conflicts; file suturing vs drop
Hi Markus, Markus Schiltknecht wrote: Can you please be more specific? Which three versions of the same file are you referring to? I only see two [...] Ok, here's the graph again. But be warned, we need a lot of characters ;) A: 1,foo,v B: 2,foo,w /\ /\ / \/ \ |\__/\ | / C: 12,foo,x | /\ |/ \ | D: 2,bar,y \ |__/ | E: 1,foo,v| \ 2,bar,y| \___| F: ??? It looks more complicated, but it isn't. I just added sort of a manifest to each revision, with the following format: REV: node_id,path,contents. A and B create foo independently, with different contents. D renames the one from B to bar and changes its content. E is a simple merge, no magic. It contains both files, foo and bar with different contents. Now, in C suturing takes place, denoted by the node_id '12' (whatever that means). In C also a content merge took place. Now, consider F, merging E and C. How does its manifest look like? I think there are two possibilities: F: 12,foo,z or F: 12,bar,z. In both cases, there are three contents to be merged: x, v, and y, and thus two content conflicts to be solved. Another variant would be: F: 12,foo,u; 2,bar,y, i.e. F containing two files. In *that* case there would indeed be only a single content conflict: merge x and v into u. What do you think F should look like in that scenario? Regards, Thomas 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] resolving name conflicts; file suturing vs drop
On Tuesday 06 May 2008, Markus Schiltknecht wrote: To be symmetric, suturing will have to drop both source files and create a new destination node. Only that way you can resurrect any of the two files later on, for example. I'm thinking of suturing as an atomic delete two, add one operation. Like that idea, and I think it would solve Nathaniel's problematic example: A B / \ /| | X | | / \| | C D |/ E Suppose A has add foo, B has add foo, D is a simple merge, so D contains a single sutured file name foo. Suppose also that C has rename foo bar, and E is a simple merge, so E has two files foo and bar. Now, I merge E and D. What happens? If D actually dropped both 'foo' nodes and created a new one 'foo' node with merged content, merging D and E would be a clean merge: drop 'foo' from A and drop 'bar' (being 'foo' from B), and add the new 'foo'. No conflict (with or without DieDieDie, in that example). *Unless*, of course, we (after killing DieDieDie) decide that changing a file's content or changing it's name causes it's aliveness state being marked for the respective revision (in the sense of *-merge)[1]. In *that* case, there would be aliveness conflicts (and probably also a chain of content conflicts following) for old 'foo' and 'foo' aka 'bar' nodes, like Nathaniel described. But that probably shouldn't scare us anymore after we have learned how to control resurrection and the content conflict chains arising there. Hm.. maybe you need to outline your graveyard concept a little better. Last I've heard about file resurrection, we should simply add a boolean flag for alive or dead. That hardly carries any extra information, but could be merged the same as other attributes. The problem is, that the all deleted files will have to stay in the rosters forever. This is not so much a problem storage-wise, because we only store leave rosters in full, and deltas for old rosters. Nevertheless it may have a serious impact on speed as we still (at least temporarily) construct a lot of full rosters for old revisions during common operations, e.g. pull. That's why I am still thinking we need a new storage scheme that allows easily access to relevant parts of a roster - as we already do for restricted log and annotate, but in a cleaner fashion. Regards, Thomas [1] Which might be reasonable: When I do change a file's name or it's contents, I'm surely making a statement that I want this file to be alive. 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] resolving name conflicts; file suturing vs drop
On Monday 05 May 2008, Ludovic Brenta wrote: It seems to me that, if the node ids were content hashes, it would solve a lot of problems. For one thing, creating two identical files would yield the same node id. For another, creating two different files with the same name on different branches would become a simple content conflict. What do you think the hash should be based on? Initial file content? While this may sound appealing, I don't think it is a good idea to use hashes instead of node ids at all. Because then to easily two files, which happen to have the same contents at birth time will erroneously (and magically, from a user's pov) get the same file identity. So we would then run into problems again. Also, think of directories, they don't have content of their own to be hashed. What we really want here, is suturing. - Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-commits-nodiffs] Revision 63a44f0a3ebbed02b4426db2edd700c5a7b03a2f
You wrote: Thomas, can you elaborate on the state of this http/json webservice you are refering to here: [EMAIL PROTECTED] wrote: First version of the plugin using the http/json webservice instead of spawning a mtn automate process itself. Some things still have to be fixed though. It sounds very interesting, but I don't currently understand how is it related to the trac plugin. It's simply that I realized that forking off and talking to a monotone subprocess from within the trac plugin is not the best thing to do, for several reasons: - Depending on how trac is deployed (e.g. if mod_python is used), it might happen that we create multiple mtn subprocesses, which will put unnecessary (memory) stress on the server and increase the chances for locking issues. - Monotone used via automate stdio currently outputs some of its error messages on stderr. But properly receiving everything from stdout *and* stderr, without blocking on stderr, is not easy (read: a big mess) to do in a portable way. You need either a non-blocking read(), or create your own eventloop, or use threads, or whatever. This is when I decided to look at twisted, which promises to exactly do that. But even using twisted, things work best if done in a stand-alone application and not in a plugin somehow executed by the webserver. That's why I created that daemon. As I currently only use it from the plugin, it lives in the same branch. It's based on twisted, right? Yes, it is. Currently, it is read-only and tries to use a simple url schema. Information is fetched from an mtn subprocess via automate stdio, parsed and then sent to the client as json encoded data. Can I run a standalone http/json service? Yeah, sure. There is some usage information at the top of twisted/plugins/mserv.py. Feel free to test it and send me comments or suggestions about it. Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] interface version / command matrix
On Saturday 29 March 2008 Thomas Keller wrote: Whether or not we're doing the cap.-bits thing it would surely be useful to define once and for all what should actually be an incompatible change. I haven't heard much of the other voices yet on this issue. One criterion could be, whether there exists (or could exist) any client using that part of the interface in the normal way (as intended by the interface's developers), that needs to be fixed to continue using that part. This is - of course - very vague. - Thomas 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] url schemes
On Saturday 29 March 2008 Philipp Gröschler wrote: To become more technical again: when in some distant future these URL features become available, would it then be possible for just any application to connect to a running 'mtn serve' process via network, issue one or more HTTP requests and get the relevant answers, without the need for this application to speak netsync? The (experimental) nvm.nuskool branch already provides something similar: You can, via scgi, connect a mtn process to a webserver and it will serve json-over-http requests. This is bidirectional: you can query for revisions, files and file deltas, and you can send new ones back. The new gsync command (also in this branch) syncs a local database against such a server. Meanwhile, I wrote a (quick'n'dirty) twisted plugin. It serves mtn content (read-only, for now) via http and json, over a tcp or a unix domain socket. Here, the requests are not coded as post-data in json, but directly in the url, very similar to those mentioned in the thread. I think I'll use that for tracmtn, so it will show up in a branch soon. Regards, Thomas 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] url schemes
Markus Schiltknecht wrote: Hm.. sounds very similar to what I've been trying... nice to hear you also like twisted as much :-) Do you mind enclosing the URL scheme you are using here? I would very much like to get something together, which would serve many use cases (i.e. dumb servers, an automate API, nuskool, maybe even xmpp..). Of course. However, I retain the right to change them if they turn out to be not as useful as I thought :) This is what is currently working (modulo bugs, of course). /revision/REV_ID /manifest/REV_ID /certs/REV_ID /file/FILE_ID (raw) /branches /tags /revisions/leaves /revisions/roots /revisions/parents/REV_ID /revisions/children/REV_ID /revisions/ancestors/REV_ID /revisions/descendants/REV_ID /revisions/select/SELECTOR /ancestry /version /cmd/COMMAND/ARG1/ARG2/... (raw) Everything not marked with (raw) is served using a json response. Slashes in the SELECTOR (and the ARGs) have to be url-escaped (%2F). The /cmd/COMMAND url simply passes through automate commands, mainly for debugging and easy access to mtn content using a browser. It cannot handle options, and is likely to disappear again. Note that while the urls are easy changeable, actually thoughts also have to be put in the design of the json responses that replace the basic_io output of mtn (for revisions, manifests, certs, etc.). Regards, Thomas 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] url schemes
Markus Schiltknecht wrote: Very nice. Really similar to what I have in mind. With the revisions, I remember doing something more like: /revision/$REVID/manifest /revision/$REVID/ancestors There is not something like a REST standard, but as far as I understood, URLs for a restful service should start with a noun denoting what is returned by that URL, and followed by some id (or, in the case of returning a set, some other arguments to further confine that set). So in my scheme, /revisions/... (plural) returns a list of revisions, /revision/... (singular) the contents of a single revision, /manifest/... returns a manifest, and so on. And I started with: /branch/$BRANCHNAME/heads That in fact can be done with a selector, so I didn't provide an URL for it. Note that while the urls are easy changeable, actually thoughts also have to be put in the design of the json responses Right. that replace the basic_io output of mtn (for revisions, manifests, certs, etc.). Replace? You mean you would completely replace the basic_io format with a json based one? Or are you speaking of the format for transmission exclusively? Instead of returning basic_io, my service returns json for everything besides file contents (and raw output in case of the backdoor /cmd/...). Regards, Thomas 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] interface version / command matrix
Stephen Leake wrote: Which means we probably should use two digits for the minor number; we'll probably have more than 10 backward-compatible changes before the next incompatible change. This is generally not a problem if you use some sort of natural sorting order for comparing revision numbers, so the parts before and after the dot are compared separately. - Thomas 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] interface version / command matrix
Thomas Keller wrote: Stephen Leake wrote: With your proposal, the automate interface version is not changed until just before the release, so my solution no longer works (for future changes). interface_version is not designed to support such things, because it would make it too complex to handle them. An easy solution to your problem could be: if you work with hand-compiled development versions of monotone, disable the version check in your application unless you work with a release version. Which brings me to the question: Why don't we abandon this serial interface-revision number at all, and replace it with a keyword-based capabilities string resp. list? This would work with a development version: together with, or directly after adding an automate function or a backwards compatible change, add the respective keyword to the list of capabilities. Each client could test on that keyword (capability) and instantaneously use the new function. If a backwards-incompatible change is made, remove the old keyword and replace it with a new one. It even works in case some other tool wants to provide a (subset of) mtn's automation interface. The subset case is (if it doesn't match that of an earlier version of 'original' monotone) impossible to announce with a single serial interface number. There's a drawback: The list of capabilities can become quite long. And, you could argue, in most cases, it doesn't provide more information than you could get by simply trying to call an automate function, and catching the error returned saying that this function doesn't exist. But then, such a list is fetched only once, so its size probably doesn't matter. - Thomas 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] interface version / command matrix
Thomas Keller wrote: Which brings me to the question: Why don't we abandon this serial interface-revision number at all, and replace it with a keyword-based capabilities string resp. list? Hrm... you left out a proposal how such a keyword-based list should look like and how human errors can be prevented when compiling it. (Yeah, I know we could just make it commandname-sequence_no and raise the latter on each change, but still, this would be hand-compiled, unless we figure out something tricky and expand the automate command class by a version field.) These are two questions. First, I /don't/ think there should be some number added to a keyword, or at least it shouldn't have a special meaning.[1] Again, in my proposal, for a backwards compatible change or a new method, a new keyword should be *added*, and for a non-compatible change (client needs to be changed if it used that functionality), a keyword should be *removed*. No versioning of keywords, because that (recursively) leads to the same problems we are discussing for the current interface_version. - Thomas [1] So (feature-1 != feature-2) but not (feature-1 feature-2) -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht wrote: No, seriously, what's the problem you want to solve fundamentally? Are you saying you never want to download revision without it's certs? Yes (...without /all/ of its certs). I know that certs are loosely coupled to their respective revision. Nevertheless, it is unexpected to get, during a sync, a revision, and all its other certs, but not its branch certs (which in turn shows, that there must be some logic explicitly blocking them, because they are, in principle, not different from the other certs that are transmitted). Regards, Thomas 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: mtn:// sync
Derek Scherger wrote: Markus Schiltknecht wrote: Hi, Thomas Moschny wrote: Ok. I vaguely had in mind that there also was a non-technical reason. I don't know any non-technical reason. I believe it's a consequence of the invariant enforced by the database that no revision will be stored unless it's parents are also stored. This ultimately requires that all ancestry for a revision is in the local database before the revision can be stored. This is clear. But the question was, is there a non-technical reason to not sync the branch certs of these ancestor revisions? Regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Friday 21 March 2008, Markus Schiltknecht wrote: Between 0.39 and now, nvm.experiment.encapsulation has landed, which has been discussed around the time of that release. Would you mind adding some words to NEWS about this, and especially about any positive (or negative?) impact this might have on the end user or on clients using the automation interface? Will all or some of the locking issues go away in 0.40? Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Tuesday 25 March 2008, Markus Schiltknecht wrote: Thomas Moschny wrote: Would you mind adding some words to NEWS about this, and especially about any positive (or negative?) impact this might have on the end user or on clients using the automation interface? Will all or some of the locking issues go away in 0.40? Thanks for the reminder, I will do -right after fixing the schema_migration test... For the end user, this change should not have any noticeable effect, except mtn being a tiny bit faster and the database taking somewhat less space. Every other difference in automate or locking behavior should be considered a bug. :-) How can the changes in nvm.experiment.encapsulation make the database take less space? And why would would you consider changes in the locking behavior a bug? In fact, the current behavior is buggy (imho), because mtn acquires coarse-grained write-locks to the database, so e.g. concurrent access via automate and mtn serve is not possible. And to me it seemed the efforts in nvmee were part of the plan to overcome this issue. Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
On Tuesday 25 March 2008, Markus Schiltknecht wrote: Thomas Moschny wrote: Any time this comes up, I wonder again, what was the argument for including revs that are ancestors of revs you want to sync, but at then excluding their branch certs? I always found this counterintuitive. I think that's just an effect of how netsync works, with its separate merkle tries for certs and revisions. Ok. I vaguely had in mind that there also was a non-technical reason. So to me, making net.venge.monotone mean net.venge.monotone.*, does look like an ugly hack to match user's expectations here without addressing the real issue. Making net.venge.monotone mean that branch and all of its children would result in fetching the associated certs as well, because all child branches were included. Thus I even think that would fix the silly issue you pointed out above, no? Exactly, but that's why I said it looks like an ugly hack. It fixes the problem accidentally, ... (For the common case of syncing net.venge.monotone, that is). ... and for a common usage pattern, but not fundamentally. Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
On Tuesday 25 March 2008, Markus Schiltknecht wrote: Does it make sense to include all those internal changes there? Hm.. probably mentioning it shortly, as I did, does not hurt, does it? What do you think? Imho NEWS isn't solely intended for the end users, but also for the 'devs' who do not following each and every commit, but want to stay up-to-date with the general picture. - Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn:// sync
On Thursday 20 March 2008, Richard Levitte wrote: Peter Stirling [EMAIL PROTECTED] said: peter Is using '' a good idea is the standard parameter divisor for parametrised URLs, so you can't get away from that without getting trouble... We could have a path-like syntax, i.e. using '/' as the divisor. This seems to be not too uncommon for web applications. Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
