<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.comp.version-control.monotone.devel">
    <title>gmane.comp.version-control.monotone.devel</title>
    <link>http://blog.gmane.org/gmane.comp.version-control.monotone.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15493"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15488"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15487"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15484"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15482"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15480"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15478"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15472"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15468"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15459"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15457"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15455"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15453"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15451"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15450"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15443"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15424"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15423"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15420"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15407"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15493">
    <title>Botan license change (patch review plz)</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15493</link>
    <description>In April 2008 the license for botan changed slightly (details at
http://lists.randombit.net/pipermail/botan-devel/2008-April/000527.html)

This patch changes three files, AUTHORS and gzip.{cc,hh}

For AUTHORS I just copied the (C) notice for botan to match the text
in nvm's botan/license.txt (presumably AUTHORS just never got updated
after the inital import of botan into nvm)

For gzip, I changed the copyright to reflect the authors and actual
in-the-legal-sense copyright holders of botan's zlib.{cpp,h} on which
the gzip implementation is based. These are Peter J Jones (of Netxx
fame) who wrote the bzip2 support for botan (actually the very first
piece of contributed code for botan), which I later copied and
modified for zlib. This does not AFAIK actually change anything,
because (since 'The Botan Project' did not exist in any legal sense)
the copyright was always actually owned by Peter and myself, so this
just changes the files to more accurately reflect reality.

I can check in if OK.

-Jack
#
# old_revis</description>
    <dc:creator>Jack Lloyd</dc:creator>
    <dc:date>2008-11-30T17:56:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15488">
    <title>using monotone for a simple logging database</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15488</link>
    <description>_______________________________________________
Monotone-devel mailing list
Monotone-devel&lt; at &gt;nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
</description>
    <dc:creator>John Wright</dc:creator>
    <dc:date>2008-11-29T00:42:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15487">
    <title>Filesystem normalisation</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15487</link>
    <description>Hi,

I've written a small module (it's one 'public' function and some  
support functions to make it
clearer as to what it's doing) that solves the 'mtn add apple Apple'  
on Mac OS X. It uses
Mac OS system calls to do its work so it will will need to only be  
compiled and linked
for that.

I've not worked with autoconf etc so I don't know how to do that  
conditional
compilation (I've made a small driver program to work on it). Since I  
don't know how
to do that I've not been able to build monotone with it, and  
consequently can't make
a monotone style unit-test, or a patch that can be applied.

The idea is to have a function
void plaform_fs_normalisation_hook( std::string &amp; const in,  
std::string &amp; out )
that can be called from
args_to_paths() (cmd.hh:146 on nvm  
93e7e626c6ee8db33a21eabcfab00d97f1bed8c2).

After the hook is complete the 'out' parameter contains either a  
version of the filename
as the filesystem stores it on disk, or it will be the same  as  
'in' (if an error occurs)
I chose to pu</description>
    <dc:creator>Peter Stirling</dc:creator>
    <dc:date>2008-11-29T05:44:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15484">
    <title>fatal: std::logic_error: paths.cc:728: invariant'I(!empty())' violated</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15484</link>
    <description>Hi,
I am getting this error when I try to do initial commit of my
/usr/local/etc:

35::root:/usr/local/etc&gt; mtn commit -m "Initial import."
mtn: beginning commit on branch 'local.radlicka.amber2/usr/local/etc'
mtn: fatal: std::logic_error: paths.cc:728: invariant 'I(!empty())' violated
mtn: this is almost certainly a bug in monotone.
mtn: please send this error message, the output of 'mtn version --full',
mtn: and a description of what you were doing to monotone-devel&lt; at &gt;nongnu.org.
mtn: wrote debugging log to /usr/local/etc/_MTN/debug
mtn: if reporting a bug, please include this file

--
VH
beginning commit on branch 'local.radlicka.amber2/usr/local/etc'
Current work set: 4 items
----- begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75)
FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 15 18:56:54 UTC 2008     root&lt; at &gt;amber2.local:/usr/obj/usr/src/sys/GENERIC i386
-----   end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), </description>
    <dc:creator>Vaclav Haisman</dc:creator>
    <dc:date>2008-11-28T11:01:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15482">
    <title>Monotone Mini Summit: 2009-01-18 - 2009-01-19</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15482</link>
    <description>Ok,

No one strongly objected to the January 18 and 19, 2009 time frame, so
let's go with that.  We should generate a list of things to work on so
that we have some direction once the mini-summit rolls around.

I made a list on IRC recently, but I have since forgotten it.  Either
way, this is what I have so far.

 * Finish wiki migration and reorganization.  I think we should spend
   some more time discussing how we will organize the new wiki.
 
 * Reorganize QuickieTasks and make it into a "Tasks" section of the
   wiki.  The idea here is to give people with time and skills a
   direction to move towards.  Ideally this new section would contain
   implementation ideas for all of the features we discuss on the
   mailing list.  For an example, see:
   http://mtn-wiki.1erlei.de/wiki/PartialPull/

Please add your ideas to this list.

</description>
    <dc:creator>Matthew A. Nicholson</dc:creator>
    <dc:date>2008-11-25T18:00:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15480">
    <title>question about multiple syncs</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15480</link>
    <description>I am working on the same project on 4 different PCs.  This means a lot
of sync operations between the repositories on the different PCs.  So
I have automated these frequent syncs using a perl script.

The problem now, is that I am often loosing track about what was
synchronized from where.  What is the most easy way to add a cert to
the repository to keep track of the original PCs where the commit was
made ?

What is the most easy way to add certs to the repository that flags a
particular revision as being synchronized to a destination repository
?

Is it possible to do this over Lua hooks ?  Performance concerns ?

Thanks,


Hugo


--

                    Hugo Cornelis Ph.D.

              Neurospaces Project Architect
                http://www.neurospaces.org/

                  Research Imaging Center
   University of Texas Health Science Center at San Antonio
                    7703 Floyd Curl Drive
                 San Antonio, TX  78284-6240

                    Phone: 210 567 8112
                  </description>
    <dc:creator>Hugo Cornelis</dc:creator>
    <dc:date>2008-11-22T00:33:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15478">
    <title>monotone-0.41 compile failure withglibc(disabled-nls)</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15478</link>
    <description>_______________________________________________
Monotone-devel mailing list
Monotone-devel&lt; at &gt;nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
</description>
    <dc:creator>Daniel Black</dc:creator>
    <dc:date>2008-11-16T18:17:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15472">
    <title>weird monotone behavior</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15472</link>
    <description>Hi,

I am using monotone 0.40 statically linked, downloaded from the
monotone website on a redhat enterprise server 5.  I encountered the
following problem:

I have a project that uses a database ~/neurospaces_project/MTN/installer.mtn

I pulled an external database of the same project to
~/neurospaces_project/MTN/neurospaces-developer.mtn

Changed the options files in a workspace, then did the things below.
In a summary, after changing the option file, asking for a log
overwrites the options file and makes it invalid.  Changing back to
the original database did not help.

Not sure if I am doing something wrong, but monotone making the
options file invalid makes me feel uncomfortable :(

[19:46] (0,2) 0 $ cat _MTN/options
database "/local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn
  branch "0"
[19:46] (0,2) 0 $ mtn log --debug
mtn: searching for '_MTN' directory with root '/'
mtn: working root is
'/local_home/hugo/neurospaces_project/installer/source/snapshots/0'
mtn: initial relative path i</description>
    <dc:creator>Hugo Cornelis</dc:creator>
    <dc:date>2008-11-16T02:22:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15468">
    <title>heads up on nvm.stripped</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15468</link>
    <description>Hi,

I've upgraded and tested nvm.stripped with the recently announced botan
1.7.21 and SQLite 3.6.5.

The code to switch sha1 engines within monotone caused problems with the
newer botan release. As we do not use that code anywhere except for the
benchmark_sha1 command, I've simply removed it. It rather looks like
botan offers something similar to benchmark various sha1 engines. I
didn't look into that, though, but don't think we need to duplicate that
work.

nvm.stripped now compiles fine and passes all tests again.

Regards

Markus Wanner



monotone 0.41 (base revision: c18c4c9d2fbcdaaf08fb448837b778e6f30968a6)
Running on          : Linux 2.6.24-rc7-cametha #1 SMP Mon Jan 14
15:31:35 CET 2008 i686
C++ compiler        : GNU C++ version 4.3.2
C++ standard library: GNU libstdc++ version 20080905
Boost version       : 1_34_1
SQLite version      : 3.6.5 (compiled against 3.6.5)
Lua version         : Lua 5.1
PCRE version        : 7.6 2008-01-28 (compiled against 7.6)
Botan version       : 1.7.21 (compiled agai</description>
    <dc:creator>Markus Wanner</dc:creator>
    <dc:date>2008-11-12T18:19:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15459">
    <title>making I(), E(),N() throw bad_decode for network data</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15459</link>
    <description>It's possible to I() a server by sending invalid data, this actually
happened here when merge_into_dir came out and not-up-to-the-minute
versions thought the resulting revisions were bogus.

I've just pushed a revision that makes the sanity macros look at a
'made_from' value, and throw bad_decode instead of their normal behavior
if that value is set to made_from_network. ATOMIC and ENCODING types and
revision_t have a member like this, and
revision_t rev;
rev.made_from = made_from_network;
read_revision(garbage_data, rev);
does actually throw bad_decode now for at least some kinds of garbage.

I don't particularly like having the macros take a "hidden" argument
like this, but I'm not sure what would be better. Having them call some
function that you can declare in your class seems slightly cleaner, but
that wouldn't allow things like
made_from_t made_from(rev.made_from);
I(rev.new_manifest == roster_manifest_id);
(database::put_roster_for_revision) and keeping the function call inside
the condition chec</description>
    <dc:creator>Timothy Brownawell</dc:creator>
    <dc:date>2008-11-10T04:26:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15457">
    <title>Monotone Lua Hook for debian/changelog</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15457</link>
    <description>_______________________________________________
Monotone-devel mailing list
Monotone-devel&lt; at &gt;nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
</description>
    <dc:creator>Richard Laager</dc:creator>
    <dc:date>2008-11-05T23:18:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15455">
    <title>Error on monotone server</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15455</link>
    <description>Hello,

I have a monotone repository being hosted on a server.  When doing a 
pull it will hang on the revisions count and sometimes require the user 
to terminate the process and attempt the pull 2 or 3 times before it 
complete successfully. 

Any idea what the problem could be?

/:mtn-heccer: peer 129.111.255.255:43506 write failed in working state 
(error)
mtn-heccer: accepted new client connection from 129.111.//255.255// : 43507
mtn-heccer: accepted new client connection from 129.111.//255.255// : 43508
mtn-heccer: peer 129.111.//255.255//:43507 read failed in working state 
(error)
mtn-heccer: allowed anonymous read permission for '*' excluding ''
mtn-heccer: finding items to synchronize:
mtn-heccer: certificates | keys | revisions
mtn-heccer:        2,861 |    2 |       916
mtn-heccer: peer 129.111.//255.255//:43508 processing finished, 
disconnecting/


-Mando
</description>
    <dc:creator>Mando Rodriguez</dc:creator>
    <dc:date>2008-11-04T20:33:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15453">
    <title>mtn buildbots</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15453</link>
    <description>Hi again,

besides the wiki, what's up with the buildbots? Most of those seem to be
more redish than green, but mostly because the bots are down. Maybe
that's a complaint towards buildbot itself, but I find it troublesome to
distinguish between monotone failures and buildbot ones.

Additionally, I'd like to start thinking about testing of nvm.stripped.
For that, the bots would need to have the required libraries installed.
Preferably with some comments about which versions of the libraries are
installed.

I'd like to add some bots with different library versions. Virtual ones
and most probably all Debian, but none the less...

Regards

Markus Wanner
</description>
    <dc:creator>Markus Wanner</dc:creator>
    <dc:date>2008-11-03T10:25:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15451">
    <title>mtn wiki</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15451</link>
    <description>Hi,

the wiki has partly been migrated to another wiki system on the last
summit. That's great, but the efforts somehow stalled. We are now left
with a wiki marked as "do not edit" for already more than half a year.

I only had a quick glance at the newish wiki branch, so I'd like to know
from those in the know:

 * what's missing on the new ikiwiki?
 * what does it take to switch to the new one?
 * what does it give us, that the former one didn't?

Regards

Markus Wanner
</description>
    <dc:creator>Markus Wanner</dc:creator>
    <dc:date>2008-11-03T10:18:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15450">
    <title>nvm.resolve_conflicts ready to land on mainline</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15450</link>
    <description>I believe nvm.resolve_conflicts is ready to land on mainline.

The main feature on this branch is the new set of commands 'mtn
conflicts *', that provide asynchronous conflict resolution, and an
automated resolution for duplicate name conflicts. More on this below.

In addition, there are some other small changes in behavior:

paths.cc normalize_external_path no longer rejects "" as a path. This
simplifies parsing the conflict resolution file, and makes other path
handling more consistent. This was discussed here briefly, with no
solid conclusion.

Several file_path functions now take an argument "to_workspace_root"
indicating that the path is relative to the workspace root, not the
current directory.

The --message or --message-file argument to merge and propagate
specify the user part of the commit message; the current 'merge rev
rev' or 'propagate from to' message is automatically prefixed. The
prefix can be suppressed by --no-prefix.


To understand the 'mnt conflicts' commands, I suggest you start by
re</description>
    <dc:creator>Stephen Leake</dc:creator>
    <dc:date>2008-11-01T16:26:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15443">
    <title>Removing database locks</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15443</link>
    <description>Hi list,

how can i simply remove monotone database lock ?
I have manipulated the database only by myself, so
this does not cause any problems.

Aarno
</description>
    <dc:creator>Aarno Syvänen</dc:creator>
    <dc:date>2008-10-29T09:47:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15424">
    <title>changing behavior of --message and --message-filefor propagate</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15424</link>
    <description>As part of implementing the resolve_conflicts commands, I'd like to
change the behavior of --message and --message-file for propagate and
merge.

I'd like mtn to insert the current message: 

propagate from branch 'testbranch2' (head c606ed519e48f526bb130fd64fef712f795f0625)
            to branch 'testbranch1' (head 04fe9ed6642b2e258162f948934726a3085e473f)

and then append the user-specified message. This allows a file-by-file
description of changes for files modified by the conflict resolution
process, similar to what we normally do for regular commits.

However, this breaks the schema_migration_with_rosterify test,
although not seriously. Part of that test compares the certs in two
databases. One of the certs is the changelog for a propagate. Normally
the two certs would be different because of different revids, but the
test uses --message-file to specify one of the changelog certs to be
the same as the other.

My change above makes the certs no longer the same.

One way to fix the schema_migration_with_r</description>
    <dc:creator>Stephen Leake</dc:creator>
    <dc:date>2008-10-26T13:58:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15423">
    <title>nvm.dates review</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15423</link>
    <description>diff -ruN S-vanilla/dates.hh S-dates/dates.hh
--- S-vanilla/dates.hh2008-05-13 20:07:26.693813111 -0700
+++ S-dates/dates.hh2008-10-25 17:07:22.986962447 -0700
&lt; at &gt;&lt; at &gt; -19,31 +19,62 &lt; at &gt;&lt; at &gt;

 struct date_t
 {
-  // For the benefit of the --date option.
-  date_t() : d("") {}
-  bool valid() const { return d != ""; }
+  // initialize to an invalid date
+  date_t() : d(-1) {}

Under what circumstances would one want a date_t with an invalid value?

+  // initialize from a unix timestamp
+  date_t(u64 d);

I am not sure I like having this be a constructor instead of a factory
function.  I don't feel strongly about it, but it was more
self-documenting the other way.  Also, you still have the ::now() and
::from_string() factories, so now there's both factories and public
constructors, which is confusing.

Also, throughout, please make all your comments be complete sentences.

+  // initialize from multiple values

"Initialize from broken-down time" would be clearer.  That is the term
used by the documentation of the C &lt;t</description>
    <dc:creator>Zack Weinberg</dc:creator>
    <dc:date>2008-10-26T01:19:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15420">
    <title>new test --no-workspace</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15420</link>
    <description>The new test '--no-workspace' fails on MinGW. I'm not clear where the
exact problem is; I get this message:

unrecognized option '--no-workspace'error: incorrect self-invocation; -r &lt;abs path to lua-testsuite.lua&gt; &lt;abs path to tester_dir&gt; &lt;test&gt;

There are other test directories whose names start with "_--"; I
assume that's the accepted fix for this as well.

I'll commit this change:

mtn rename tests/--no-workspace tests/_--no-workspace

--
</description>
    <dc:creator>Stephen Leake</dc:creator>
    <dc:date>2008-10-25T22:08:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15407">
    <title>compilation failure on Win32 MinGW</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15407</link>
    <description>compile on Win32 MinGW is failing with:

make[3]: *** No rule to make target `../monotone/botan/big_base.cpp', needed by `botan/lib3rdparty_a-big_base.o'.  Stop.

Is that a generated file, or did it just not get checked in?

</description>
    <dc:creator>Stephen Leake</dc:creator>
    <dc:date>2008-10-25T15:42:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15398">
    <title>Lua loading dynamic libraries not possible inmonotone?</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.monotone.devel/15398</link>
    <description>Hello!

Can someone comment on this bug

https://savannah.nongnu.org/bugs/?24639

? What is causing it? Is it a bug or is it by intention? I'd like to 
create hooks in monotone that need to run native code. The only way to 
do so is to create a dynamically loadable library, load it from within 
my Lua script and execute code of it. However, when doing so, monotone 
Lua says that the support for this feature is missing. Any ideas why?

The platform itself supports this. When downloading and building Lua 
command line interpreter, I can run the code and it works just fine.

Kindest regards,
Markus
</description>
    <dc:creator>Markus Hanauska</dc:creator>
    <dc:date>2008-10-24T12:43:03</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.comp.version-control.monotone.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.version-control.monotone.devel</link>
  </textinput>
</rdf:RDF>
