Re: [Monotone-devel] Re: nvm.stripped

[Patrick Georgi]

Derek Scherger schrieb:
> On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg <[EMAIL PROTECTED]
> > wrote:
>
> I put some patches on .library-build to deal with this.  The 'best
> effort' functionality is not available in 1.5 as far as I know, but I
> don't know any reason why the //TRANSLIT//IGNORE thing that we had
> before the 'best effort' patches isn't good enough...  Lapo is perhaps
>
>
> That's what I was wondering too. I also wonder if maybe libidn might
> have fixed the problem in the intervening 5 years since Graydon
> grabbed a copy. IIRC Lapo was fighting with the changelog comment on
> one particular revision in the monotone history. It would be
> interesting to have this test case if we can dig it up. In the
> meantime I'll probably just move the //TRANSLIT stuff up into
> charset.cc and then go ahead with switching to the system installed
> libidn.
Isn't the //TRANSLIT//IGNORE thing a libiconv or gettext issue? It
shouldn't have anything to do with libidn in particular.


Regards,
Patrick Georgi


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] advice, please, on organising branches

[hendrik]

On Sun, Oct 12, 2008 at 06:58:52PM -0700, Zack Weinberg wrote:
> On Mon, Oct 13, 2008 at 12:04 AM,  <[EMAIL PROTECTED]> wrote:
> > I'm working on in a compiler that will at some time have multiple code
> > generators.  These will target different so-called machine-independent
> > intermediate codes, and will be appropriate in different execution
> > environments.
> >
> > The obvious way to organise this is as a tree of branches
> 
> Why are you trying to isolate each code generator in its own branch?
> Wouldn't it make more sense to isolate each one in its own *files*,
> and have them all present in the checkout at the same time?

Yeah ... good question.  The different code generators share a lot of 
code, and to a large extend the same structure.  It would be convenient 
to make changes to the common code once and propagate changes into 
the different code generators.  The common code is closely 
interleaved with the generator-specific code, so isolating more of the 
common code in separate files is infeasible, especially because the 
language in which it's all written is a relic from the 60's and is 
actively hostile to breaking programs into separate files.

Still, I'll have to look at this carefully.  It's still possible that 
separate files is the best solution.

-- hendrik


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] set verses vector in args_to_paths

[Derek Scherger]

On Sun, Oct 12, 2008 at 6:28 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote:

The only thing I'd be worried about is making sure we're not doing a
> std::set copy now (which is more expensive than a std::vector copy).
> Restriction objects tend to be on the stack so maybe they don't need
> to copy (constructor takes a reference?)


I'm not sure copies would even be all that bad, I'd be surprised if we make
very many copies of these things (a few 10's at most?) and they're probably
small sets for the most part (i.e. the files you included on the command
line to status/diff/commit/etc.)

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] advice, please, on organising branches

[Zack Weinberg]

On Mon, Oct 13, 2008 at 12:04 AM,  <[EMAIL PROTECTED]> wrote:
> I'm working on in a compiler that will at some time have multiple code
> generators.  These will target different so-called machine-independent
> intermediate codes, and will be appropriate in different execution
> environments.
>
> The obvious way to organise this is as a tree of branches

Why are you trying to isolate each code generator in its own branch?
Wouldn't it make more sense to isolate each one in its own *files*,
and have them all present in the checkout at the same time?

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] advice, please, on organising branches

[hendrik]

I'm working on in a compiler that will at some time have multiple code 
generators.  These will target different so-called machine-independent 
intermediate codes, and will be appropriate in different execution 
environments.

The obvious way to organise this is as a tree of branches

A
   /|\
  / | \
 J  L  C

where A is the ancestral compiler with a skeletal code generator (which 
generates no code), and where J, L, and C are the same skeletal code 
generator fleshed out to the different intermediate codes.

A bug in L could, for example, be fixed in L of in A depending on how 
branch-specific it is, and then merged into J and L.  That's one of the 
recommended best practices on the wiki.

The trouble is that what I have checked in now is the code for the J 
branch, and the code for the A branch does not exist (and never has).

I'd have to build a common ancestor A from J, and then spawn L and C.

How awkward!

Now I could just discard J as a separate branch, since its target 
intermediate code is technically obsolete and has no surviving 
implementation (the compiler is ancient; so is J) and just derive

J
|\
| \
L  C

or even

J
|
|
A
|\
| \
L  C

which would be technically more honest.

Could anyone advise which organisation they consider better?  Or is 
there another I'm missing completely?

-- hendrik



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] mtn db check

[Daniel Carrera]

Timothy Brownawell wrote:
"missing manifests that are referenced by their sha1 hash from some 
revision but do not exist in the database."

...

We used to store these, but switched to storing "rosters" instead. These
are like manifests, but they also include various cached values that
speed up merging.


Oh! then the documentation really needs updating. The quote I took was 
just an example. About half of the documentation for "db check" talks 
about manifests.


Thanks for the explanation. Is there documentation on rosters? I don't 
know what those are and I'm happy to read the documentation.


Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] set verses vector in args_to_paths

[Zack Weinberg]

On Sun, Oct 12, 2008 at 5:20 PM, Derek Scherger <[EMAIL PROTECTED]> wrote:
> When I was fiddling with the include/exclude stuff I noticed that
> args_to_paths returns a vector of paths which is used almost exclusively in
> calls to restriction constructors.

"It was that way when I got here." :-)

> These quickly turn the vectors into sets
> of paths and I wondered whether it would be better if everything just worked
> in terms of sets.

The only thing I'd be worried about is making sure we're not doing a
std::set copy now (which is more expensive than a std::vector copy).
Restriction objects tend to be on the stack so maybe they don't need
to copy (constructor takes a reference?)

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] set verses vector in args_to_paths

[Derek Scherger]

When I was fiddling with the include/exclude stuff I noticed that
args_to_paths returns a vector of paths which is used almost exclusively in
calls to restriction constructors. These quickly turn the vectors into sets
of paths and I wondered whether it would be better if everything just worked
in terms of sets. Does anyone (maybe in particular Zack) have an opinion on
this? I have a vague suspicion that they were originally sets and got
switched to vectors for some reason or another but haven't had time to
check. I have made a quick change to return std::set from args_to_paths and
all the restriction constructors and all the tests seem to pass with this so
there's no obvious reason not to commit it.

Thanks,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Derek Scherger]

On Sun, Oct 12, 2008 at 3:32 PM, Thomas Keller <[EMAIL PROTECTED]> wrote:

> Derek Scherger schrieb:
> > Since 0.40 there is a new hook `get_default_command_options` which could
> >
> >
> > Hrm, I hadn't used that before, but it does seem nice. Was it added just
> > after 0.40 or is it included in 0.40?  (my system installed 0.40 doesn't
> > seem to have it but more recent builds do)
>
> Sorry, my bad, it was 0.41 where I introduced that. And I agree that a
>

No worries, I was just confused for a minute.


> frontend command would be nicer for this, but I wanted to note that its
> possible and available ;)
>

Ok good, it is good to know that there are other possibilities too. I'll
commit what I have to a branch and we can bat it around a bit.

Just to be clear, it does not use a versioned .mtn-exclude file at the
moment though. I currently have unversioned workspace files in _MTN/includes
and _MTN/excludes containing the accumulated mtn include and mtn exclude
paths respectively. The contents of these files are literally just added to
the list of paths specified to various commands or to the list of
--excludes.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: nvm.stripped

[Derek Scherger]

On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote:

> I put some patches on .library-build to deal with this.  The 'best
> effort' functionality is not available in 1.5 as far as I know, but I
> don't know any reason why the //TRANSLIT//IGNORE thing that we had
> before the 'best effort' patches isn't good enough...  Lapo is perhaps
>

That's what I was wondering too. I also wonder if maybe libidn might have
fixed the problem in the intervening 5 years since Graydon grabbed a copy.
IIRC Lapo was fighting with the changelog comment on one particular revision
in the monotone history. It would be interesting to have this test case if
we can dig it up. In the meantime I'll probably just move the //TRANSLIT
stuff up into charset.cc and then go ahead with switching to the system
installed libidn.


> the only person who would know.
>

Yeah, hopefully he reads some of this at some point. ;)

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

[Jack Lloyd]

On Sun, Oct 12, 2008 at 06:26:52PM -0400, Jack Lloyd wrote:
> On Sun, Oct 12, 2008 at 03:48:25PM -0500, Timothy Brownawell wrote:
> > > Unrelated thought: would it make sense for mtn version --full to print
> > > out the version #s of the various libraries, since they are no longer
> > > fixed by the monotone version?
> > 
> > Sounds like a good idea.
> 
> I've attached a patch.

New version. Use the version macros for Botan instead of calling the
string function. Mostly for consistency with the rest of the version #
sources.

#
# old_revision [17398bbfe76852cb9ac73cf3cb13912050982e1a]
#
# patch "mt_version.cc"
#  from [271946e05e232569f97b685e3354819a81683643]
#to [1e46c73a8a617ac7db3edd5ee9a8f06a28743046]
#

--- mt_version.cc   271946e05e232569f97b685e3354819a81683643
+++ mt_version.cc   1e46c73a8a617ac7db3edd5ee9a8f06a28743046
@@ -19,8 +19,15 @@
 #include 
 #include 
 
+/* Include third party headers needed for version info */
+#include 
+#include 
+// Lua assumed included by lua.hh
+#include 
+
 #include "app_state.hh"
 #include "cmd.hh"
+#include "lua.hh"
 #include "platform.hh"
 #include "mt_version.hh"
 #include "package_revision.h"
@@ -74,12 +81,20 @@ get_full_version(string & out)
"C++ compiler: %s\n"
"C++ standard library: %s\n"
"Boost version   : %s\n"
+   "SQLite version  : %s\n"
+   "Lua version : %s\n"
+   "PCRE version: %d.%d\n"
+   "Botan version   : %d.%d.%d\n"
"Changes since base revision:\n"
"%s")
 % s
 % BOOST_COMPILER
 % BOOST_STDLIB
 % BOOST_LIB_VERSION
+% SQLITE_VERSION
+% LUA_RELEASE
+% PCRE_MAJOR % PCRE_MINOR
+% BOTAN_VERSION_MAJOR % BOTAN_VERSION_MINOR % BOTAN_VERSION_PATCH
 % string(package_full_revision_constant);
   out = oss.str();
 }
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

[Jack Lloyd]

On Sun, Oct 12, 2008 at 03:48:25PM -0500, Timothy Brownawell wrote:
> > Unrelated thought: would it make sense for mtn version --full to print
> > out the version #s of the various libraries, since they are no longer
> > fixed by the monotone version?
> 
> Sounds like a good idea.

I've attached a patch.

One thing I was not sure about.

pcrewrap.cc includes pcre.h as

#include "pcre.h"

Is this a leftover of in-tree PCRE?

I used

#include 

in this patch.

-Jack
#
# old_revision [17398bbfe76852cb9ac73cf3cb13912050982e1a]
#
# patch "mt_version.cc"
#  from [271946e05e232569f97b685e3354819a81683643]
#to [707eeef64c013362ebf76d9adbf9e711a5487369]
#

--- mt_version.cc   271946e05e232569f97b685e3354819a81683643
+++ mt_version.cc   707eeef64c013362ebf76d9adbf9e711a5487369
@@ -19,8 +19,15 @@
 #include 
 #include 
 
+/* Include third party headers needed for version info */
+#include 
+#include 
+// Lua assumed included by lua.hh
+#include 
+
 #include "app_state.hh"
 #include "cmd.hh"
+#include "lua.hh"
 #include "platform.hh"
 #include "mt_version.hh"
 #include "package_revision.h"
@@ -74,12 +81,20 @@ get_full_version(string & out)
"C++ compiler: %s\n"
"C++ standard library: %s\n"
"Boost version   : %s\n"
+   "SQLite version  : %s\n"
+   "Lua version : %s\n"
+   "PCRE version: %d.%d\n"
+   "Botan version   : %s\n"
"Changes since base revision:\n"
"%s")
 % s
 % BOOST_COMPILER
 % BOOST_STDLIB
 % BOOST_LIB_VERSION
+% SQLITE_VERSION
+% LUA_RELEASE
+% PCRE_MAJOR % PCRE_MINOR
+% Botan::version_string()
 % string(package_full_revision_constant);
   out = oss.str();
 }
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

[Jack Lloyd]

On Sun, Oct 12, 2008 at 03:48:25PM -0500, Timothy Brownawell wrote:
> On Sun, 2008-10-12 at 15:34 -0400, Jack Lloyd wrote:
> > I built nvm.stripped b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1 against
> > SQlite 3.5.9, Botan n.r.botan head, PCRE 7.7, Lua 5.1.3 on my
> > Gentoo/Core2 box, GCC 4.3.2. make check had two failures:
> > 
> > 192 empty_environment FAIL (line 29)
> > 203 fail_cleanly_on_unreadable_db FAIL (line 62)
> > 
> > 203 failure is known, I don't know what 192 is about (how can I find
> > out? I couldn't find any log files). The output I have is attached.
> 
> Should be tester_dir/tests/$NAME/tester.log
> 

Thanks! (Turns out the failure of empty_environment was just a dynamic
link error - almost certainly because I was doing rebuilds of 
libbotan-1.7.18.so right as the test suite was running)

-Jack


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] mtn db check

[Timothy Brownawell]

On Sun, 2008-10-12 at 19:33 +0200, Daniel Carrera wrote:
> Hello,
> 
> I'm reading the documentation of mtn db check. It says that, among other 
> things, this command will detect the following problem:
> 
> "missing manifests that are referenced by their sha1 hash from some 
> revision but do not exist in the database."

Hmm, it sounds like the documentation is outdated since we don't
actually store manifests anymore.

> My question: What is a manifest?

It's the integral of your revision history.

revision 1
add_dir "."
add_file "foo" [da39...]

revision 2
parent "..."
add_file "bar" [1234...]
rename "foo" "xyzzy"

manifest of revision 2
directory "."
file "bar" [1234...]
file "xyzzy" [da39...]

You can get one from "mtn au get_manifest_of ".

We used to store these, but switched to storing "rosters" instead. These
are like manifests, but they also include various cached values that
speed up merging.

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Thomas Keller]

Derek Scherger schrieb:
> Since 0.40 there is a new hook `get_default_command_options` which could
> 
> 
> Hrm, I hadn't used that before, but it does seem nice. Was it added just
> after 0.40 or is it included in 0.40?  (my system installed 0.40 doesn't
> seem to have it but more recent builds do)

Sorry, my bad, it was 0.41 where I introduced that. And I agree that a
frontend command would be nicer for this, but I wanted to note that its
possible and available ;)

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Stephen Leake]

"Derek Scherger" <[EMAIL PROTECTED]> writes:

> Was it added just after 0.40 or is it included in 0.40? (my system
> installed 0.40 doesn't seem to have it but more recent builds do)

I think we should bump the version number in the sources immediately
_after_ a release, just to avoid this kind of confusion.

-- 
-- Stephe


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Stephen Leake]

"Derek Scherger" <[EMAIL PROTECTED]> writes:

> This change isn't about ignoring unversioned files but about temporarily
> ignoring changes to versioned files. I.e. restricting
> status/diff/commit/etc. to specified sets of files, which is already
> possible with command line path arguments. This just allows for a persistent
> selection of changed files so that several status/diff/etc. commands can be
> executed without having to specify the same set of paths every time. It also
> allows for successive refinement of the set of included/excluded
> files.

I implemented just such a feature in the Emacs DVC interface to
monotone; it would make sense to have a .mtn-exclude file for this.

I use it to exclude Makefiles by default, since we typically edit them
temporarily to compile and run debug code. From the Emacs DVC
interface, they can be un-excluded for any particular commit.

I suggest that if .mtn-exclude is implemented, there be a --unexclude
option to override the settings in .mtn-exclude for a file for one
commit.

-- 
-- Stephe


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: nvm.stripped

[Zack Weinberg]

On Sat, Oct 11, 2008 at 9:28 PM, Derek Scherger <[EMAIL PROTECTED]> wrote:
> I'm now looking at idna (libidn) which ought to be easy but isn't because of
> some changes that were made at the 2007 summit iirc. Lapo, do you recall the
> "best effort" stuff that got added to idna/toutf8.c? This is not in idna 1.5
> but I'm wondering if maybe idna 1.5 might just do the right thing?

I put some patches on .library-build to deal with this.  The 'best
effort' functionality is not available in 1.5 as far as I know, but I
don't know any reason why the //TRANSLIT//IGNORE thing that we had
before the 'best effort' patches isn't good enough...  Lapo is perhaps
the only person who would know.

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

[Timothy Brownawell]

On Sun, 2008-10-12 at 15:34 -0400, Jack Lloyd wrote:
> I built nvm.stripped b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1 against
> SQlite 3.5.9, Botan n.r.botan head, PCRE 7.7, Lua 5.1.3 on my
> Gentoo/Core2 box, GCC 4.3.2. make check had two failures:
> 
> 192 empty_environment FAIL (line 29)
> 203 fail_cleanly_on_unreadable_db FAIL (line 62)
> 
> 203 failure is known, I don't know what 192 is about (how can I find
> out? I couldn't find any log files). The output I have is attached.

Should be tester_dir/tests/$NAME/tester.log

> Unrelated thought: would it make sense for mtn version --full to print
> out the version #s of the various libraries, since they are no longer
> fixed by the monotone version?

Sounds like a good idea.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Derek Scherger]

On Sun, Oct 12, 2008 at 11:54 AM, Thomas Keller <[EMAIL PROTECTED]> wrote:

>
> The question is probably where and how long these things should persist.


My expectation is that they would be relatively transient. One use-case is
selecting things I'm preparing to commit by looking at status and diff,
including/excluding some things, repeatedly until I'm satisfied. However, I
can also think of less transient use cases, where in some workspace I don't
want certain portions of the tree, which I could exclude and then remove
similar to a partial checkout case. (I think I've seen people interested in
partial checkouts here haven't I?)

I know, one shouldn't commit partial, untested changes, but occasionally, it
happens and I think I prefer to commit related but possibly untested things
rather than mix unrelated things together.

Since 0.40 there is a new hook `get_default_command_options` which could


Hrm, I hadn't used that before, but it does seem nice. Was it added just
after 0.40 or is it included in 0.40?  (my system installed 0.40 doesn't
seem to have it but more recent builds do)

be used for that as well (you could easily put this into the per-project
> _MTN/monotonerc):
>
> function get_default_command_options(command)
>local default_opts = {}
>if (command[1] == "diff" or command[1] == "status") then
>table.insert(default_opts, "--include=foo")
>table.insert(default_opts, "--exclude=bar")
>end
>return default_opts
> end


I agree that this could serve the same purpose, but it seems more cumbersome
for the transient case. In the more permanent case it would probably be ok.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: nvm.stripped

[Derek Scherger]

On Sun, Oct 12, 2008 at 10:13 AM, Jack Lloyd <[EMAIL PROTECTED]> wrote:

> Two things on nvm.stripped (rev b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1)
>
> I am warned:
>
> Makefile.am:339: whitespace following trailing backslash
>
> There is a trailing tab on that line.
>
> Also, here is the output currently when configure encounters a version
> of Botan from the future:
>
> checking for Botan... configure: WARNING: Your botan library version
> (1.7.18) is newer than expected. Monotone might not build cleanly.
> yes (version 1.7.18)
>
> By reordering the messages in botan.m4
> more readable output is produced:
>
> checking for Botan... yes (version 1.7.18)
> configure: WARNING: Your botan library version (1.7.18) is newer than
> expected. Monotone might not build cleanly.
>
>
Thanks, I've committed these changes in
17398bbfe76852cb9ac73cf3cb13912050982e1a

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Thomas Keller]

Derek Scherger schrieb:
> I had an idea the other day, where I was continually having to provide a
> bunch of --exclude optons in a workspace with some (intentionally) missing
> files, that it might be useful to be able to specify a set of includes or
> excludes that persist across several commands. This would avoid the need to
> repeatedly specify the set of paths to include or exclude. It turns out to
> be very simple to implement and I have a the basics working so I thought I'd
> check and see if people would generally find this good, bad or ugly.
> 
> The basic idea is:
> 
> $ mtn include aaa bbb ccc
> $ mtn exclude ddd eee fff
> $ mtn status
> Including:
>   aaa
>   bbb
>   ccc
> Excluding:
>   ddd
>   eee
>   fff
> Current branch: ...
> Changes against parent ...

The question is probably where and how long these things should persist.

Since 0.40 there is a new hook `get_default_command_options` which could
be used for that as well (you could easily put this into the per-project
_MTN/monotonerc):

function get_default_command_options(command)
local default_opts = {}
if (command[1] == "diff" or command[1] == "status") then
table.insert(default_opts, "--include=foo")
table.insert(default_opts, "--exclude=bar")
end
return default_opts
end

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] mtn db check

[Daniel Carrera]

Hello,

I'm reading the documentation of mtn db check. It says that, among other 
things, this command will detect the following problem:


"missing manifests that are referenced by their sha1 hash from some 
revision but do not exist in the database."



My question: What is a manifest?

Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: nvm.stripped

[Jack Lloyd]

On Sun, Oct 12, 2008 at 09:53:34AM -0600, Derek Scherger wrote:

> Heh, just noticed that too. I've merged and pushed so things are good. I
> removed -DTEMP_STORE from AM_CFLAGS in Makefile.am in the merged version. As
> near as I can tell this was only relevant for SQLITE.

Two things on nvm.stripped (rev b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1)

I am warned:

Makefile.am:339: whitespace following trailing backslash

There is a trailing tab on that line.

Also, here is the output currently when configure encounters a version
of Botan from the future:

checking for Botan... configure: WARNING: Your botan library version (1.7.18) 
is newer than expected. Monotone might not build cleanly.
yes (version 1.7.18)

By reordering the messages in botan.m4

#
# old_revision [b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1]
#
# patch "m4/botan.m4"
#  from [c3b115c9be716601db0f21612a5a6b1e4ac720ab]
#to [e9cd9dc87a81965e626353055f6c58c86a63d947]
#

--- m4/botan.m4 c3b115c9be716601db0f21612a5a6b1e4ac720ab
+++ m4/botan.m4 e9cd9dc87a81965e626353055f6c58c86a63d947
@@ -43,13 +43,14 @@ AC_DEFUN([MTN_FIND_BOTAN],
 #endif],
 [botan_version_match=yes],
 [botan_version_match=no])
-if test $botan_version_match = no; then
-  AC_MSG_WARN([Your botan library version ($BOTAN_VERSION) is newer than 
expected. Monotone might not build cleanly.])
-fi
 
 CPPFLAGS="$save_CPPFLAGS"
 AC_MSG_RESULT([yes (version $BOTAN_VERSION)])
 
+if test $botan_version_match = no; then
+  AC_MSG_WARN([Your botan library version ($BOTAN_VERSION) is newer than 
expected. Monotone might not build cleanly.])
+fi
+
 # AC_MSG_NOTICE([using botan compile flags: "$BOTAN_CPPFLAGS"])
 # AC_MSG_NOTICE([using botan link flags: "$BOTAN_LIBS"])


more readable output is produced:

checking for Botan... yes (version 1.7.18)
configure: WARNING: Your botan library version (1.7.18) is newer than expected. 
Monotone might not build cleanly.

-Jack


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] db kill_rev_locally

[Ethan Blanton]

Daniel Carrera spake unto us the following wisdom:
> Thanks. I believe I understand the technique now. Make a dummy account  
> where all the devs login and give them a shell that does nothing. It's  
> very good, and it seems to work in every case in which my initial  
> proposal works. It'd be nice if it was documented on the website 
> somewhere.

It is not documented on the web site simply because this is a standard
way to provide a private service.  It is by no means specific to
monotone, nor is monotone particularly suited to it more than other
services.

That said, if and when the wiki ever reappears, if you wanted to write
up a quick HOWTO I am sure it would be appreciated.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764


signature.asc
Description: Digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Derek Scherger]

On Sun, Oct 12, 2008 at 3:31 AM, Brian May
<[EMAIL PROTECTED]>wrote:

> Derek Scherger wrote:
>
>> I had an idea the other day, where I was continually having to provide a
>> bunch of --exclude optons in a workspace with some (intentionally) missing
>> files, that it might be useful to be able to specify a set of includes or
>> excludes that persist across several commands. This would avoid the need to
>> repeatedly specify the set of paths to include or exclude. It turns out to
>> be very simple to implement and I have a the basics working so I thought I'd
>> check and see if people would generally find this good, bad or ugly.
>>
>
> Maybe I missed something, but are you aware of the ".mtn-ignore" file used
> by the default ignore_file LUA hook? This might already do what you want...


This change isn't about ignoring unversioned files but about temporarily
ignoring changes to versioned files. I.e. restricting
status/diff/commit/etc. to specified sets of files, which is already
possible with command line path arguments. This just allows for a persistent
selection of changed files so that several status/diff/etc. commands can be
executed without having to specify the same set of paths every time. It also
allows for successive refinement of the set of included/excluded files.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: nvm.stripped

[Derek Scherger]

On Sun, Oct 12, 2008 at 7:31 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:

>
> > and also moved sqlite to the Attic
>
> ..oops, looks like we've done duplicate work. I've just committed and
> pushed what I have. It's not quite complete, yet (rev
> 4c625e162bf17c69406de23482187313dafd29cd). Have you pushed your work, yet?
>

Heh, just noticed that too. I've merged and pushed so things are good. I
removed -DTEMP_STORE from AM_CFLAGS in Makefile.am in the merged version. As
near as I can tell this was only relevant for SQLITE.

Okay, so I let you take care of libidn. If you don't mind, I'll follow
> the sqlite things and try to fix those tests. Certainly not today,
> though.  ... just trying to avoid duplicate work...
>

Sure, sounds good.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?

[Markus Wanner]

Hi,

Ralf S. Engelschall wrote:
> Ok, I finally found time to finish the preparation of the SQLite
> upgrade. Sorry for the delay, I was heavily busy because of my day job.
> I've pushed the following two branches to monotone.ca today:
> 
> o net.venge.monotone.rse.sqlite-upgrade
> ...
> o net.venge.monotone.rse.sqlite-upgrade-amalgamation
> ...

I've revisited those branches, but decided to follow the spirit of
nvm.stripped and made mtn link against a system provided sqlite3 library
instead, at least for the nvm.stripped branch for now.

We can still revert to include the amalgamation later on, I think.
What's most important for me now is making monotone compatible with
newer sqlite versions.

Do you mind suspending these branches?

Regards

Markus Wanner






___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: nvm.stripped

[Markus Wanner]

Hi,

Derek Scherger wrote:
> I've made this change

Cool, thanks.

> and also moved sqlite to the Attic 

..oops, looks like we've done duplicate work. I've just committed and
pushed what I have. It's not quite complete, yet (rev
4c625e162bf17c69406de23482187313dafd29cd). Have you pushed your work, yet?

> which went much
> more smoothly than I was expecting since it involved upgrading from 3.4.2 to
> 3.5.9. One test fails with this later change, fail_cleanly_on_unreadable_db,
> which I assume is an actual change in sqlite behaviour but I'm not certain
> of this.

Yes, Ralf S. Engelschall has noted that before, see my other mail.

I've tested my variant against sqlite 3.3.8 (included in debian etch),
3.5.9 (debian testing, IIRC) and 3.6.3 (current stable release). These
tests fail:


sqlite 3.3.8:

146 database_checkFAIL (line 23)
192 empty_environment FAIL (line 29)
203 fail_cleanly_on_unreadable_db unexpected success
216 i_selectorFAIL (line 32)

(does not have the 'hex()' function, but obviously works like we expect
for 'fail_cleanly_on_unreadable_db')


sqlite 3.5.9:

192 empty_environment FAIL (line 29)
203 fail_cleanly_on_unreadable_db FAIL (line 62)

sqlite 3.6.3:

192 empty_environment FAIL (line 29)
203 fail_cleanly_on_unreadable_db FAIL (line 62)


The 'empty_environment' test fails due to LD_LIBRARY_PATH required for
building against libraries in non-standard locations.

> I'm now looking at idna (libidn) which ought to be easy but isn't because of
> some changes that were made at the 2007 summit iirc. Lapo, do you recall the
> "best effort" stuff that got added to idna/toutf8.c? This is not in idna 1.5
> but I'm wondering if maybe idna 1.5 might just do the right thing?

Okay, so I let you take care of libidn. If you don't mind, I'll follow
the sqlite things and try to fix those tests. Certainly not today,
though.  ... just trying to avoid duplicate work...

Regards

Markus Wanner



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] db kill_rev_locally

[Daniel Carrera]

Ludovic Brenta wrote:

Which would require me to have SSH login ("daniel"). What am I missing?


You are correct but the [EMAIL PROTECTED] account may be
unprivileged (running a restricted shell) and shared with other
developers.  You might as well call it after the project the
developers work on, e.g. [EMAIL PROTECTED]  The monotone
server itself, and the database, belong to and run as a different
user, e.g. [EMAIL PROTECTED]


Thanks. I believe I understand the technique now. Make a dummy account 
where all the devs login and give them a shell that does nothing. It's 
very good, and it seems to work in every case in which my initial 
proposal works. It'd be nice if it was documented on the website somewhere.




I run a public monotone server on www.ada-france.org; see
http://www.ada-france.org/article131.html for explanations.  The
security model is simple: everyone has read access, and only a few
trusted developers have write access to the entire database (they can
create branches at will).  Because this is a netsync server running as
a "monotone" user that has /bin/false as its shell, only sysadmins
with root access to the machine can delete from this database.


Thanks. I'll read that article.

Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Thomas Keller]

Brian May schrieb:
> Thomas Keller wrote:
>> I'd do it "safely" without messing around with _MTN/revision and move
>> the current changes aside to re-apply them later on:
>>
>> $ mtn diff > current_changes.txt
>> $ mtn revert .
>> $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
>> $ patch -p0 < current_changes.txt
>>   
> Unfortunately it won't work if you have renamed files, for example.

Yeah, I know, I know. The same goes out for attributes. But as I said
earlier, I really would like to have an mtn patch command, which would
solve these issues. Still, the proposed workflow works reasonable well
for small changes in existing files.

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] new include/exclude commands?

[Brian May]

Derek Scherger wrote:
I had an idea the other day, where I was continually having to provide 
a bunch of --exclude optons in a workspace with some (intentionally) 
missing files, that it might be useful to be able to specify a set of 
includes or excludes that persist across several commands. This would 
avoid the need to repeatedly specify the set of paths to include or 
exclude. It turns out to be very simple to implement and I have a the 
basics working so I thought I'd check and see if people would 
generally find this good, bad or ugly.


Maybe I missed something, but are you aware of the ".mtn-ignore" file 
used by the default ignore_file LUA hook? This might already do what you 
want...



Brian May


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Brian May]

Thomas Keller wrote:

I'd do it "safely" without messing around with _MTN/revision and move
the current changes aside to re-apply them later on:

$ mtn diff > current_changes.txt
$ mtn revert .
$ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
$ patch -p0 < current_changes.txt
  

Unfortunately it won't work if you have renamed files, for example.

I really liked the tla undo/redo options. I found some documentation here:



Brian May


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] db kill_rev_locally

[Ludovic Brenta]

Daniel Carrera writes:
> Ethan Blanton wrote:
>> Then, to connect to the server, run something like the following on
>> your workstation:
>>
>> ssh -L4691:localhost:4691 
>
> Could you clarify this command? My reading of it is:
>
> ssh -L4691:localhost:4691 [EMAIL PROTECTED]
>
>
> Which would require me to have SSH login ("daniel"). What am I missing?

You are correct but the [EMAIL PROTECTED] account may be
unprivileged (running a restricted shell) and shared with other
developers.  You might as well call it after the project the
developers work on, e.g. [EMAIL PROTECTED]  The monotone
server itself, and the database, belong to and run as a different
user, e.g. [EMAIL PROTECTED]

I run a public monotone server on www.ada-france.org; see
http://www.ada-france.org/article131.html for explanations.  The
security model is simple: everyone has read access, and only a few
trusted developers have write access to the entire database (they can
create branches at will).  Because this is a netsync server running as
a "monotone" user that has /bin/false as its shell, only sysadmins
with root access to the machine can delete from this database.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel