Re: Is monotone dead, or is there a path forward?

[Stephen Leake]

Hendrik Boom  writes:

> On Sat, Jun 05, 2021 at 08:54:25AM -0700, Stephen Leake wrote:
>> Hendrik Boom  writes:
>> 
>> > Or is monotone development and maintenance truly dead and I need to 
>> > abandon ship and take what data I ca with me?
>> 
>> Just for reference, I gave up on monotone, and exported to git.
>
> I stopped liking git when I learned about its limitations on merging and 
> the need for rebasing. 
>
> Of course I never really liked git in the first place.
>
> monotone got merging branches right.

I heartily agree, but I have to use some cm tool, and maintaining enough
of monotone to keep it working was more than I could handle.

-- 
-- Stephe

Re: Is monotone dead, or is there a path forward?

[Stephen Leake]

Hendrik Boom  writes:

> Or is monotone development and maintenance truly dead and I need to 
> abandon ship and take what data I ca with me?

Just for reference, I gave up on monotone, and exported to git.

-- 
-- Stephe

Re: terminating branch development

[Stephen Leake]

Hendrik Boom  writes:

> Is there a way to tell monotone that a named branch is no longer of interest 
> (except perhaps for historians)?

mtn suspend

https://www.monotone.ca/docs/Branching-and-Merging.html

-- 
-- Stephe

Re: aborting a merge

[Stephen Leake]

Hendrik Boom  writes:

> Let's say I do a propagate from a main branch to a development branch.
> I get dumped into emacs merge to sort things out.
> Let's further say the emacs merge gets too hairy.  I need to do 
> the merge more slowly with other tools, or perhaps start the merge 
> over again, with more insight.
>
> How do I get out of emacs merge mode without letting monotone 
> think the merge has been completed?

Don't save the buffer; that will tell monotone to abort.



-- 
-- Stephe

no monotone in Debian testing?

[Stephen Leake]

I've just installed a new Debian 10 VM, and upgraded to testing.

'aptitude search monotone' returns nothing!

Is it finally time to stop using monotone?

-- 
-- Stephe

Re: [Monotone-devel] interoperating with git

[Stephen Leake]

Hendrik Boom  writes:

> Planning to use monotone together with git.  Monotone for day-to-day 
> activity, because it's a system I understand and trust.  Git for posting 
> working versions on github or gitlab or some such.
>
> The obvious way to do this is to have one workspace that is used with 
> both git and monotone.  git will be tld to ignore _MTN; monotone will be 
> told to ignore .git .

I've done this with monotone and bazaar. It works, but is somewhat
tedious, since you end up doing every commit twice (possibly grouped
into larger commits for git, but still similar amount of work). I have
some support for this in the Emacs DVC frontend - avalable from the
ada-france monotone repository (see
http://www.nongnu.org/ada-mode/ada-france-access.html for contact info).

A better option with monotone and git is to export the monotone db to a
git repository. I have not done this yet, but others have reported
success. Search this mailing list archive.

-- 
-- Stephe

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

Re: [Monotone-devel] serialization format

[Stephen Leake]

Markus Wanner <mar...@bluegap.ch> writes:

> On 04/07/2016 05:21 PM, Stephen Leake wrote:
>> Peter Stirling <pe...@pjstirling.plus.com> writes:
>>> I apologise for being late to the part here: Is the goal here to
>>> reduce the barrier to entry for automate clients (by using something
>>> which has a decent chance of having a parsing library in most
>>> languages)?
>
> Yes, that'd be one of the nice properties of a standard format; whether
> its a binary (e.g. ASN.1) or textual (e.g. YAML) one.
>
>> But only if the current output is preserved as an option; I've got it
>> working with Emacs. Which is a non-starter; we don't have enough
>> manpower to maintain two output formats.
>
> Well, I'm willing to put some effort into it and I certainly value
> backwards compatibility as well, yes. However, there can only be one
> format that monotone uses internally (think pre vs post flag day). 

There's a version number in the internal format, so we don't need a flag
day (or maybe that was on a branch; anyway, we can add one). We do need
to maintain both formats for compatibility with old databases.

-- 
-- Stephe

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

Re: [Monotone-devel] serialization format

[Stephen Leake]

Peter Stirling  writes:

> I apologise for being late to the part here: Is the goal here to
> reduce the barrier to entry for automate clients (by using something
> which has a decent chance of having a parsing library in most
> languages)?

That is a reasonable goal.

But only if the current output is preserved as an option; I've got it
working with Emacs. Which is a non-starter; we don't have enough
manpower to maintain two output formats.

-- 
-- Stephe

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

Re: [Monotone-devel] serialization format

[Stephen Leake]

Markus Wanner <mar...@bluegap.ch> writes:

> Hello Stephen,
>
> thanks for your feedback.
>
> On 04/04/2016 06:58 PM, Stephen Leake wrote:
>> Human readable makes testing and developing new features much easier. If
>> we use binary, we will need a separate tool that translates that to
>> readable, which is then another source of bugs (or the same source, just
>> in a different place).
>
> Yeah, that's a point. However, I'd also argue that we should target the
> user and not the developer. And from a user's perspective, isn't
> monotone the very tool that does that kind of translation?
>
> Or put another way: Do *users* really care what serialization format
> monotone uses underneath?

No, users don't care (as long as the tools work).

Caveat; if they have to compose an email with the Monotone output (to
send it somewhere), ASCII text is safer than binary.

But that means they have no opinion on basic_io vs json, either.

Unless there are _other_ tools (not provided by monotone) that users
could use with Monotone output if it was other than basic_io.


-- 
-- Stephe

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

Re: [Monotone-devel] serialization format

[Stephen Leake]

Markus Wanner  writes:

> Hi,
>
> I'd like to get some feedback regarding some ideas around the
> serialization format used for storage and exchange of data in monotone.
> Currently, we're mostly using basic_io (for revisions, manifests, certs,
> AFAIK even for automate).
>
> Three things are bug me about basic_io:
>
>  * while well readable, it's a custom format, not used anywhere else
>
>  * it's flat and cannot represent nested structures
>
>  * it cannot handle binary data (therefore monotone is spending quite a
>bit of time converting between hex and raw data (mostly revision
>ids))
>
>
> There are plenty of alternatives when considering a binary format: good
> old ASN.1, Google Protocol Buffers, MessagePack, Blink, etc...
>
> Human readable alternatives (which would at least eliminate the first
> two concerns) might be: JSON, YAML, or (bear with me) even XML. But for
> hashes and such we need a canonical format. And nothing for those three
> remains readable in any of their canonical forms that I've seen so far.
>
>
> At the moment, the most important question seems to be: how much do you
> value the human readable representation? How about a binary format that
> you can easily transform to and from a human readable one?

Human readable makes testing and developing new features much easier. If
we use binary, we will need a separate tool that translates that to
readable, which is then another source of bugs (or the same source, just
in a different place).

Unless you are planning major work on monotone, it's not worth changing
from basic_io.

-- 
-- Stephe

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

Re: [Monotone-devel] deferred merge

[Stephen Leake]

Hendrik Boom  writes:

> Is there some easy oe-time way of asking a merge to be deferred, so 
> that the "merged" file has both versions in it, complete with 
> '' and ">>>" and ssuch to mark the conflicts?  Because 
> sometimes it takes a lot more analysis than is practical with the emacs 
> merge command.

You can use the "conflicts" set of commands; see
http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

They let you output a list of the conflicts that will occur during a
merge, and create files that resolve the conflicts. Then when all the
conflicts are resolved, you can do the actual merge.

I implemented those commands precisely to allow more time for conflict
resolution.


-- 
-- Stephe

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

Re: [Monotone-devel] deleting databases

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 Rereading the tutorial for the first time in years I discovered the llovely 
 command 

 $ mtn db init --db=:beth

 in section 2.3, which creates a database in a standard location, 
 normally $HOME/.monotone/databases

 I immediately tried it out, and created

 ~/.monotone/databases/onion.mtn

 And, of course, I then wondered how to delete it again.


 Now I get to ask -- does monotone keep any information on this 
 database  outside of the database itself and the _MTN directories in 
 its workspaces.

No, that is the only persistent storage mtn uses.

 Because if not, I can delete it with a simple
   rm ~/.monotone/databases/onion.mtn

Yes, that suffices.

Unless, of course, you have synced it somewhere.

-- 
-- Stephe

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

Re: [Monotone-devel] improving `mtn status`

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 it's been a while since the C++11 refactoring, but as promised, here's
 some actually useful work: I scratched a couple of itches I had with
 recent monotone's status command and started a branch trying to improve
 it: net.venge.monotone.revamp-status.

Thanks for working on mtn!

I never use 'mtn status', except to check that the Emacs DVC front end
isn't lying to me :).

So as long as you don't change 'mtn auto inventory', this does not
affect me.

But the changes you describe sound reasonable.

One goal might be to make it closer to 'git status', and or 'hg status',
so people migrating to/from those are comfortable.

 The fundamental conceptual mismatch is that the current `mtn status`
 basically answers the question: what would happen, if I tried to commit
 this, now? Where as I expect it to provide more general information
 about the status of my working tree. Oftentimes without any intention of
 committing.

+1

 Another naughty example - which I consider a bug - is `mtn status` on a
 working tree that misses files known to the parent revision (or has
 mismatches in type - i.e. file vs directory). For example:

 mtn: warning: missing file 'm4/stlporthashmap.m4'
 mtn: warning: not a file 'Attic/m4'
 mtn: warning: expected file 'Attic/m4', but it is a directory.
 mtn: warning: missing file 'm4/tr1unorderedmap.m4'
 mtn: misuse: 3 missing items; use 'mtn ls missing' to view.
 mtn: misuse: To restore consistency, on each missing item run either
 mtn: misuse:  'mtn drop ITEM' to remove it permanently, or
 mtn: misuse:  'mtn revert ITEM' to restore it.
 mtn: misuse: To handle all at once, simply use
 mtn: misuse:  'mtn drop --missing' or
 mtn: misuse:  'mtn revert --missing'

 Even though some files are missing, mtn should still be able to give me
 more elaborate status information - rather than forcing the user to fix
 these issues, first.

+1

This happens on 'mtn update' as well; that annoys me, since 'update' is
very similar to 'revert'! Perhaps we need an 'update --revert', meaning
revert as needed, then update.

-- 
-- Stephe

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

Re: [Monotone-devel] [Monotone-users] I'm sorry to keep bothering you

[Stephen Leake]

jfl j...@i2pmail.org writes:

 mkdir ~/mtn/ooncd ; cd ~/mtn/ooncd
 mtn db init --db=ooncd
 mtn --db=ooncd --branch=th.or.ooncd-th setup th
 cd th
 cp -r ../../ooncd-old/th/rst .
 cp ../../ooncd-old/th/makefile .
 mtn add -R rst makefile
 mtn commit -kjfl-transport@mail.i2p --message=initial checkin of ooncd-th
 cd ..
 ...
 mtn pull mtn://127.0.0.1:8990/ooncd
   mtn: misuse: no database specified

 +++

 I don't understand why the branch is empty, or why I even need a key
 to run the clone command ...

I don't see where you tried to run clone.

 So, I tried pull ... but monotone doesn't know what I'm talking about.

The error message is almost clear; you did not tell mtn what database to
pull _to_; you only told it what database to pull _from_.

_if_ mtn is run in a workspace, it uses the defaults specified in
_MTN/options. But your 'pull' command is not in a workspace; it is in
~/mtn/ooncd, the workspace is in ~/mtn/ooncd/th

So you need:

mtn -d ~/mtn/ooncd/ooncd pull mtn://127.0.0.1:8990/ooncd

or:

cd th
mtn pull mtn://127.0.0.1:8990/ooncd

 Why does 'k' take just one dash, no space, and the keyname in some
 commands and the 'normal' two dashes, '=', and the keyname in quotes
 in others?

You can always use either; '-kname' is short for '--key=name'.

-- 
-- Stephe

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

Re: [Monotone-devel] [Monotone-users] multiple databases on a single machine

[Stephen Leake]

jfl j...@i2pmail.org writes:

 I have 2 databases, one with 2 branches and one with 4. I want to
 serve them both from the same machine. 

I have not done this, but I believe the anser is usher: 

http://journal.richard.levitte.org/entries/transparent-usher/

-- 
-- Stephe

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

Re: [Monotone-devel] [Monotone-users] botan

[Stephen Leake]

jfl j...@i2pmail.org writes:

 Is it ok to install and run a version of botan separate from and
 possibly a different version than what's in monotone without dangerous
 and/or confusing interactions?

depends on the OS, and what you mean by separate.

This is a general shared library configuration management question, not
specific to monotone.

mtn must use the shared library it was compiled for, or a strictly
upward-compatible one. I don't know if Botan is in general
upward-compatible, but I wouldn't bet on it.

Debian (and Linux in general) has facilities for installing multiple
versions shared libraries for exactly this reason.

On Windows, you must put the botan .dll in the same directory as
mtn.exe, or ensure it is the only on PATH.

-- 
-- Stephe

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

Re: [Monotone-devel] fixing old commit messages

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 Is there any way to edit an old commit message?

The commit message for a revision is stored in the changlog cert:

$ mtn ls certs h:org.opentoken
mtn: expanding selection 'h:org.opentoken'
mtn: expanded to '99db28068fc5a79e3e613f8d64dc273a4870'

Key   : stephen_leak...@stephe-leake.org (ed5da650ec...)
Sig   : ok
Name  : author
Value : stephen_leak...@stephe-leake.org

Key   : stephen_leak...@stephe-leake.org (ed5da650ec...)
Sig   : ok
Name  : branch
Value : org.opentoken

Key   : stephen_leak...@stephe-leake.org (ed5da650ec...)
Sig   : ok
Name  : changelog
Value : * opentoken-recognizer-graphic_character.adb (Analyze): fix if/then 
layout
  : * opentoken-recognizer-html_entity.adb (Analyze):
  : * opentoken-recognizer-real.adb:
  : * opentoken-token-enumerated-analyzer.adb (Find_Best_Match):

Key   : stephen_leak...@stephe-leake.org (ed5da650ec...)
Sig   : ok
Name  : date
Value : 2014-06-14T06:41:14


You can't delete or change an old cert, but you can add a new one:

$ mtn cert h:org.opentoken changelog additional changelog

However, that might cause problems with tools that expect only one
changelog per revision.

So the best answer is no, you can't change commit messages.

Part of the point of the name monotone is that history changes
monotonically; you can only add to it, never subtract (a change is a
subtract plus add).

-- 
-- Stephe

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

Re: [Monotone-devel] minimum requirements

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 As per the build farm, these platforms now compile nvm.mandatory-cxx11
 just fine:
   CentOS 6.5 (using g++ 4.8.2 from devtools-2 package)
   Cygwin
   Debian sid
   Gentoo Hardened
   MinGW / Msys 1.0
   NetBSD 6.1 (using gcc48)
   OmniOS r151008 (pretending to be SunOS 5.11)
   Ubuntu precise

 Manual testing additionally yields good results on:
   Debian stable
   FreeBSD 10
   Mac OS X 10.8 (Mountain Lion)

and MinGW / Msys 2.0 32 and 64 bit.

 Given the above successes, the lack of offers to help with other
 platforms and baring further objections, I plan to land
 nvm.mandatory-cxx11 within the next few days.

+1

-- 
-- Stephe

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

Re: [Monotone-devel] mandatory-cxx11 on Cygwin doesn't have to_string

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 searching for to_string in /usr/include turns up boost references
 only.

 On Cygwin, the stdc++ headers live under /usr/lib/gcc/.

arrgghh.

 Bottom line: It looks like we're stuck with boost::lexical_cast for
 now. Therefore, I reverted the corresponding changes in
 nvm.mandatory-cxx11.

Ok.

-- 
-- Stephe

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

[Monotone-devel] mandatory-cxx11 on Cygwin doesn't have to_string

[Stephen Leake]

Cygwin g++ is:

g++ --version
g++ (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.

Cygwin does not provide to_string in the string header:

../mandatory-cxx11/src/sanity.cc:38:12: error: ‘std::to_string’ has not
been declared

(even after adding #include string)

searching for to_string in /usr/include turns up boost references
only.

reverting all uses of to_string, stoi, and similar lexical casts lets
mtn compile.

Any clues?

-- 
-- Stephe

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

Re: [Monotone-devel] minimum requirements

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/16/2014 07:12 PM, Markus Wanner wrote:
 Stephen wants these (and supports them by occasional manual testing):
  * RHEL 6

 Minor update on the RHEL front: build animal armadillo (effectively
 running CentOS 6.5) now uses a g++ 4.8.2 from the devtools-2 package.

 With that, it now fails to compile nvm, because with the new compiler,
 C++11 gets enabled. But the old boost headers on that platform do not
 seem to cope well with C++11. So using C++11 with old-ish boost
 (armadillo uses boost 1.41) doesn't work.

I install boost headers from source, not from the RPM package. I forgot
that part.

 Note that the branch nvm.mandatory-cxx11 works just fine (as it doesn't
 use much of boost, anymore). So does disabling C++11 on nvm.

Ok.

 To me, that's yet another argument to mandate C++11: 

yes.

-- 
-- Stephe

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

Re: [Monotone-devel] mandatory-cxx11 on Cygwin doesn't have to_string

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 reverting all uses of to_string, stoi, and similar lexical casts lets
 mtn compile.

And pass all tests.

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 We can put such things in src/base.hh or add to CXXFLAGS via the
 configure script. I personally prefer the former, but we need to
 consider that it has no effect on the embedded netxx sources. 

netxx/* apparently doesn't include base.hh; undefining __STRICT_ANSI__
is also required in nextxx/datagram.cxx. 

So now Cygwin compiles nvm. Tests running ...

 (Actually an argument to get rid of those...)

Is that what the nvm.asio branch is for?

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Apparently 'std::shared_ptrvoid' is illegal, and that is enforced in
 gcc 4.9.0

 Yeah, seems like a weird construct.

 cow_trie::_data is set by the 'walk' code above; apparently we have two
 node types. So to use a shared_ptr, we need a union of those types.

 ..or give the two a common base class?

done, tested, pushed.

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/16/2014 05:17 PM, Stephen Leake wrote:
 Markus Wanner mar...@bluegap.ch writes:
 
 Interesting, I thought I tested that. But you're right, this looks like
 the macro doesn't do what it's supposed to do. It itself claims:

 #   The first argument, if specified, indicates whether you insist on an
 #   extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g.
 #   -std=c++11).  If neither is specified, you get whatever works, with
 #   preference for an extended mode.

 I left it unspecified, as I'm fine with whatever works (tm).

 I corrected the order of tests, now. So for gcc, it now yields the c++??
 rather than gnu++?? variants.
 
 But it says with preference for an extended mode., which means it
 should pick gnu++ if both work. Which is what it did.

 Oh, right, I read that the wrong way around. Thanks for clarifying.

 Either way, the script now does what we want it to do. I should adjust
 the comment, though.

 If we are also supporting clang and MSVC, we need c++11, not gnu++11 (I 
 think).

 Well, the intent of the script is to *test* what works and what not.
 (And MSVC needs an entirely different build system.)

I meant we need to enforce using only standard C++ 2011 constructs, and
not allow Gnu extensions, since the Gnu extensions are not likely to be
supported by clang and MSVC.

-- 
-- Stephe

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

Re: [Monotone-devel] minimum requirements

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Stephen wants these (and supports them by occasional manual testing):
  * RHEL 6
  * Windows / Msys 2
  * Cygwin

Someone else (Lapo? ) has been providing Cygwin packages, but 1.1 hasn't
happened yet.

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

LeJacq, Jean Pierre jeanpierre.lej...@quoininc.com writes:

 error: ‘fdopen’ was not declared in this scope *in = fdopen(infds[1], w);
 

 Setting the language level to -std='c++11' enables strict ISO C++ library 
 support. fdopen() is not part of the C11 or C++11 standards. Instead it is a 
 POSIX function.

Ok.

   -D'_POSIX_SOURCE=1'
   -D'_POSIX_C_SOURCE=200809L'
   -D'_XOPEN_SOURCE=700'
   -D'_XOPEN_SOURCE_EXTENDED=1'

 GNU extensions can then be enabled using:

   -D'_GNU_SOURCE=1'

Is there a separate include file for posix? That would be cleaner than
messing with these macros.

-- 
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
 that; I have Redhat 6 64 bit.

Done, and passing.

Any objections to propagating nvm.msys2-mingw-64 to nvm?

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/15/2014 09:18 PM, Stephen Leake wrote:
 gcc --version
 gcc (GCC) 4.7.4 20131104 for GNAT Pro 7.2.1 (20140108)

 for GNAT Pro?!?

yes; it's for my day job, we pay for AdaCore support.

I'm not suggesting it as a general solution for mtn on Red Hat 6, but it
works for me.

 In file included from ../mandatory-cxx11/src/globish.cc:14:0:
 ../mandatory-cxx11/src/option.hh: In member function
 option::option_setT option::option_setT::operator|(const
 option::option_setT) const':
 ../mandatory-cxx11/src/option.hh:332:7: error: 'set_union' is not a
 member of 'std'

 Does that g++ version compile plain nvm? That's is using the very same
 standard library functions from algorithm...

But options.hh does not have #include algorithm . Adding that fixes
the problem; mtn compiles (tests running ...).

Apparently #include algorithm is implied somehow, or included in
another include file, in nvm? 

Or it's actually a bug in older versions of the g++ std library, now
fixed in 4.7.4.

 Also, I notice you are using -std=gnu++11; shouldn't that be
 -std=iso9899:2011, so we don't rely on gnu extensions?

 The m4 script is supposed to use -std=gnu++11 only if -std=c++11 is not
 supported. I haven't ever seen -std=iso9899:2011, before, but certainly
 prefer the shorter variant.

I found it from 'g++ -v --help'

 Does your g++ support -std=c++11? 

Yes (it's in the same help listing).

 If so, it looks like the m4 macro is failing to do its job properly.

config.log says it checks 'g++' first (default language version), then
'g++ -std=gnu++11', and that works, so it is used.

So yes, this is a bug in the m4 macro.

--
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/16/2014 11:34 AM, Stephen Leake wrote:
 Stephen Leake stephen_le...@stephe-leake.org writes:
 I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
 that; I have Redhat 6 64 bit.
 
 Done, and passing.
 
 Any objections to propagating nvm.msys2-mingw-64 to nvm?

 No, looks fine from here. Cleared to land.

Done.

Then propagated nvm to nvm.mandatory-cxx11, so I can test with msys2 mingw64

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Interesting, I thought I tested that. But you're right, this looks like
 the macro doesn't do what it's supposed to do. It itself claims:

 #   The first argument, if specified, indicates whether you insist on an
 #   extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g.
 #   -std=c++11).  If neither is specified, you get whatever works, with
 #   preference for an extended mode.

 I left it unspecified, as I'm fine with whatever works (tm).

 I corrected the order of tests, now. So for gcc, it now yields the c++??
 rather than gnu++?? variants.

But it says with preference for an extended mode., which means it
should pick gnu++ if both work. Which is what it did.

If we are also supporting clang and MSVC, we need c++11, not gnu++11 (I think).

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 On Tue, May 13, 2014 at 07:23:07PM +0200, Markus Wanner wrote:
 
 This requirement clearly complicates matters for distributions that ship
 anything older than gcc-4.6. These are (according to what I could find
 quickly):
 
   Debian squeeze (oldstable): shipping gcc 4.4

 Unfortunately, it looks like squeeze is going to be picked for 
 long-term support.

picked by who? The Debian project?

 (Why, why, couldn't they haave picked wheezy for this?)

That does seem very odd.

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

On msys2:

g++ --version
g++.exe (Rev2, Built by MSYS2 project) 4.9.0

g++  -I. -I../mandatory-cxx11   -I/mingw64/include 
-I/mingw64/include/botan-1.10-DWIN32 -DNETXX_NO_PTON -DNETXX_NO_NTOP 
-DNETXX_NO_INET6   -g -O2 -Wall -Wextra -Wno-unused -Wno-unused-parameter 
-std=c++11 -MT src/roster.o -MD -MP -MF $depbase.Tpo -c -o src/roster.o 
../mandatory-cxx11/src/roster.cc \
mv -f $depbase.Tpo $depbase.Po
In file included from 
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr.h:52:0,
 from C:/Msys2/msys64/mingw64/include/c++/4.9.0/memory:82,
 from ../mandatory-cxx11/src/roster.cc:14:
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr_base.h: In 
instantiation of 'std::__shared_ptr_Tp, _Lp::__shared_ptr(_Tp1*) [with _Tp1 = 
cow_trieunsigned int, std::shared_ptrmarking, 8::middle_node_type; _Tp = 
void; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]':
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr_base.h:1023:4:   
required from 'void std::__shared_ptr_Tp, _Lp::reset(_Tp1*) [with _Tp1 = 
cow_trieunsigned int, std::shared_ptrmarking, 8::middle_node_type; _Tp = 
void; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]'
../mandatory-cxx11/src/cow_trie.hh:48:4:   required from 'bool cow_trie_Key, 
_Value, _Bits::walk(std::shared_ptrvoid, _Key, int, _Value**) [with _Key = 
unsigned int; _Value = std::shared_ptrmarking; int _Bits = 8]'
../mandatory-cxx11/src/cow_trie.hh:135:38:   required from 'const _Value 
cow_trie_Key, _Value, _Bits::get_unshared_if_present(_Key) [with _Key = 
unsigned int; _Value = std::shared_ptrmarking; int _Bits = 8]'
../mandatory-cxx11/src/roster.cc:212:59:   required from here
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr_base.h:874:4: error: 
static assertion failed: incomplete type
static_assert( !is_void_Tp::value, incomplete type );


I think the problem is in cow_trie.hh:

  bool walk(std::shared_ptrvoid  d, _Key key, int level, _Value **ret)
  {
if (!d)
  {
if (level  0)
  d.reset(new middle_node_type());
else
  d.reset(new leaf_node_type());
  }

Apparently 'std::shared_ptrvoid' is illegal, and that is enforced in
gcc 4.9.0

I don't have the c++11 reference manual. I found this:

http://en.cppreference.com/w/cpp/memory/shared_ptr

std::shared_ptr may be used with an incomplete type T, but T must be
complete at the point in code where the constructor from a raw
pointer or the reset(T*) member function is called (note that
std::unique_ptr may be constructed from a raw pointer to an
incomplete type).

I assume 'void' is an incomplete type. 

The parameter 'd' in 'walk' is used to pass cow_trie::_data.

cow_trie::_data is set by the 'walk' code above; apparently we have two
node types. So to use a shared_ptr, we need a union of those types.

Can we use a unique_ptr here? I don't see where _data is shared. Guess I
should just try it: no, that gives a different error:

g++  -I. -I../mandatory-cxx11   -I/mingw64/include 
-I/mingw64/include/botan-1.10-DWIN32 -DNETXX_NO_PTON -DNETXX_NO_NTOP 
-DNETXX_NO_INET6   -g -O2 -Wall -Wextra -Wno-unused -Wno-unused-parameter 
-std=c++11 -MT src/cmd_netsync.o -MD -MP -MF $depbase.Tpo -c -o 
src/cmd_netsync.o ../mandatory-cxx11/src/cmd_netsync.cc \
mv -f $depbase.Tpo $depbase.Po
In file included from C:/Msys2/msys64/mingw64/include/c++/4.9.0/memory:81:0,
 from 
C:/Msys2/msys64/mingw64/include/boost/container/container_fwd.hpp:36,
 from 
C:/Msys2/msys64/mingw64/include/boost/lexical_cast.hpp:170,
 from ../mandatory-cxx11/src/lexical_cast.hh:13,
 from ../mandatory-cxx11/src/option.hh:29,
 from ../mandatory-cxx11/src/options.hh:26,
 from ../mandatory-cxx11/src/commands.hh:14,
 from ../mandatory-cxx11/src/cmd.hh:17,
 from ../mandatory-cxx11/src/cmd_netsync.cc:13:
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/unique_ptr.h: In instantiation 
of 'void std::default_delete_Tp::operator()(_Tp*) const [with _Tp = void]':
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/unique_ptr.h:236:16:   required 
from 'std::unique_ptr_Tp, _Dp::~unique_ptr() [with _Tp = void; _Dp = 
std::default_deletevoid]'
../mandatory-cxx11/src/cow_trie.hh:20:7:   required from here
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/unique_ptr.h:72:2: error: static 
assertion failed: can't delete pointer to incomplete type
  static_assert(!is_void_Tp::value,


So we need a union type.

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

   NetBSD 5.1  shipping gcc 3.3
   OpenBSD 5.5 shipping gcc 4.2
   Debian squeeze (oldstable): shipping gcc 4.4
   Ubuntu 10.04 LTS (lucid):   shipping gcc 4.4
   RHEL 6: shipping gcc 4.4
   CentOS 6.5: shipping gcc 4.4
   FreeBSD 9.0 shipping gcc 4.4
   Fedora 14:  shipping gcc 4.5
   OpenSuse 11.4   shipping gcc 4.5
   Slackware 13.37 shipping gcc 4.5

 These (and newer) should be fine:

   Ubuntu LTS 12.04 (precise): shipping 4.4 - 4.8
   Debian stable (wheezy): shipping 4.6 and 4.8
   Fedora 15:  shipping gcc 4.6
   FreeBSD 9.2 shipping gcc 4.6
   OpenSuse 12.1:  shipping gcc 4.6
   Slackware 14.0  shipping gcc 4.7
   NetBSD 6.1  shipping gcc 4.8
   RHEL 7  shipping gcc 4.8 (?)

Thanks for the list.

You left out Windows:

msys2 mingw64   4.9
cygwin 64 bit   4.8

 Out of these, RHEL 6 hurts the most, IMO. 

Yes. That's the required OS for my day job, which is where I use mtn the
most. And I want to stay with mtn head, so I can add new conflict
resolutions etc :).

We also have to run RHEL 5 for a couple of version-frozen projects. But
those don't need the latest monotone, just netsync compatibility.

 However, there's the RedHat Developer Toolset, shipping gcc 4.7. 

I was not aware of that, nor of RHEL 7.

In addition, we use AdaCore tools, which provide gcc 4.7. I'll
try testing with that.

 For other old distributions still in use, you're likely to find a
 newer gcc as well, I think.

Right. Or just use an older monotone; as long as we preserve netsync
compatibility, using an older monotone is not a serious problem. People
using old systems have to accept old tools.

We could provide 1.1 source tarball on our website for a while, to allow
compiling on non-C++-11 systems.

We don't have the manpower to maintain two distributions.

We don't want to discourage interested contributors by saying you can't
use the best tool for the job (which would actually be Ada 2012, not
C++ 11, but let's not go there :).

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Given the (lack of) manpower, I think it's actually beneficial to the
 project to reduce the variety of supported platforms. 

Yes.

 I'm certainly not willing to test gccs back to version 3.2. Nor boost
 as of 1.33, for example. (As currently stated in INSTALL.) I'd also
 like to drop support for botan 1.6, maybe even 1.8.

Once we settle on the required OS mininum versions, we should declare
the dependent package versions they ship as the minimums.

 Three years after release 1.0, I think it's about time to discuss the
 set of supported platforms.

Yes.

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 Markus Wanner mar...@bluegap.ch writes:

   NetBSD 5.1  shipping gcc 3.3
   OpenBSD 5.5 shipping gcc 4.2
   Debian squeeze (oldstable): shipping gcc 4.4
   Ubuntu 10.04 LTS (lucid):   shipping gcc 4.4
   RHEL 6: shipping gcc 4.4
   CentOS 6.5: shipping gcc 4.4
   FreeBSD 9.0 shipping gcc 4.4
   Fedora 14:  shipping gcc 4.5
   OpenSuse 11.4   shipping gcc 4.5
   Slackware 13.37 shipping gcc 4.5

 These (and newer) should be fine:

   Ubuntu LTS 12.04 (precise): shipping 4.4 - 4.8
   Debian stable (wheezy): shipping 4.6 and 4.8
   Fedora 15:  shipping gcc 4.6
   FreeBSD 9.2 shipping gcc 4.6
   OpenSuse 12.1:  shipping gcc 4.6
   Slackware 14.0  shipping gcc 4.7
   NetBSD 6.1  shipping gcc 4.8
   RHEL 7  shipping gcc 4.8 (?)

 Thanks for the list.

 You left out Windows:

 msys2 mingw64   4.9
 cygwin 64 bit   4.8

 Out of these, RHEL 6 hurts the most, IMO. 

 Yes. That's the required OS for my day job, which is where I use mtn the
 most. And I want to stay with mtn head, so I can add new conflict
 resolutions etc :).

 We also have to run RHEL 5 for a couple of version-frozen projects. But
 those don't need the latest monotone, just netsync compatibility.

 However, there's the RedHat Developer Toolset, shipping gcc 4.7. 

 I was not aware of that, nor of RHEL 7.

 In addition, we use AdaCore tools, which provide gcc 4.7. I'll
 try testing with that.

Not good:

gcc --version
gcc (GCC) 4.7.4 20131104 for GNAT Pro 7.2.1 (20140108)

In file included from ../mandatory-cxx11/src/globish.cc:14:0:
../mandatory-cxx11/src/option.hh: In member function
option::option_setT option::option_setT::operator|(const
option::option_setT) const':
../mandatory-cxx11/src/option.hh:332:7: error: 'set_union' is not a member of 
'std'
../mandatory-cxx11/src/option.hh: In member function
option::option_setT option::option_setT::operator-(const
option::option_setT) const':
../mandatory-cxx11/src/option.hh:340:7: error: 'set_difference' is not a member 
of 'std'
../mandatory-cxx11/src/globish.cc: In function
std::basic_stringchar::const_iterator compile_charclass(const
string, std::basic_stringchar::const_iterator,
std::back_insert_iteratorstd::basic_stringchar , origin::type)':
../mandatory-cxx11/src/globish.cc:141:7: error: 'sort' is not a member of 'std'


Also, I notice you are using -std=gnu++11; shouldn't that be
-std=iso9899:2011, so we don't rely on gnu extensions?

-- 
-- Stephe

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

Re: [Monotone-devel] C++11

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 The most obvious drawback is higher requirements on compilers and
 standard libraries. However, it seems realistic to be able to support
 gcc-4.6 and clang-3.3 and newer. (Maybe even older clang, but I didn't
 try.)

I have no problem moving to the current language standard, as long as we
can actually compile everything we need.

 Is anybody opposed to raising these? Are you fine with landing these
 branches and start to use C++11?

We need to show that all (most?) tests pass on the various supported platforms
before merging to nvm.

I can test on 64 bit and 32 bit msys2/ming64, 32 bit Debian stable, and
64 bit Red Hat 6.

What platforms have you tested this on?

-- 
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/06/2014 02:15 AM, Stephen Leake wrote:
 Yes, as long as there are no warnings in the compiler output, my
 workflow works :).

 I'm glad to hear that.

 Anything speaking against landing nvm.cleanup-warnings, then?

No, go ahead.

I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
that; I have Redhat 6 64 bit.

 We should add something about this in HACKING, and perhaps suggest
 compiling new code with -Wunused enabled, to catch bugs before they get
 too far.

 Yeah. One hurdle there is that you cannot just pass that in CXXFLAGS,
 but have to adjust m4/prog_cxx_warnings.m4. :-(

I would just edit the Makefile after configure. I do that to change -O2
to -O0 for debugging, as well.

-- 
-- Stephe

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

Re: [Monotone-devel] GPL version for monotone

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 while COPYING states GPL-2+ as the license for monotone, I just figured
 there's exactly two files in the source that state GPL-3+:
 src/{unix,win32}/parse_date.cc. You introduced these back in May 2010 in
 rev a8147b11, when splitting functionality from dates.cc into these two
 platform specific variants.

Right.

 I realize the has been some discussion regarding switching to GPL-3+
 (search the archives for GPLv3 code in monotone), but to me the thread
 doesn't quite look like an agreement has been reached for a move to
 GPL-3+. 

Right; it was a mistake to use GPLv3 in that code.

 Maybe that needs to be revisited, now? Stephen, do you want to pursue
 a move to GPL-3+, again?

I'm always in favor of moving to GPLv3, but I don't think anything has
changed in this regard.

 Alternatively, please resolve the ambiguity by clearly allowing
 distribution of those files under GPL v2 as well, i.e. change the boiler
 plate there to state GNU GPL version 2.0 or greater, as other source
 files still do. Thanks.

Done

-- 
-- Stephe

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

Re: [Monotone-devel] monotone 1.1 released

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/04/2014 03:20 PM, Stephen Leake wrote:
 Will you be doing the win32 installer? I can build one from an msys2 32
 bit build, if needed.

 I'd appreciate if you do it. Thanks.

My ssh key has been lost from mtn-uplo...@monotone.ca, so I can't
upload.

How do we fix that?

-- 
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 I understand your point of view and appreciate your efforts. Please
 continue to maintain the msys2 documentation.

Ok, thanks.

 I'm not quite satisfied with the general guide for Windows, though, so
 please allow me to write something. I think that may well fit into
 INSTALL itself.

Ok.

 Do you have any useful hints for what build system to choose for
 Windows? I mean Cygwin vs the others is somewhat obvious - either you
 want that POSIX emulation layer or you don't. 

Right.

 But all of the MinGW versions confuse me a lot. Why did you choose
 MinGW64 over MinGW-w64 (!) [0], for example? 

There are a lot of ways to use MinGW64; it is confusing.

I did not try them all; I only tried downloading from the MinGW64 site,
and the Msys2 site.

I went with Msys2 because it has a good package manager, an almost
complete set of packages for monotone (only Botan needed to be compiled
from source), can run autotools and configure, and a helpful email list.

 What about the different C++ exception and threading models? Which one
 did you (or mingw/msys2) use? 

It was chosen by Msys2 when they packaged MinGW64; I don't know which
they picked. It should be possible to find out from the Msys2 project.
But at this point, I also don't care :).

 What effect do these options possibly have on monotone? 

No idea, except it's pretty minor. We use exceptions for error handling,
not for mainline processing.

 Let alone the issue of cross-compiling 32-bit binaries from a 64-bit
 system  tool chain. 

The tool chain installed in msys2/mingw32 is a 32 bit toolchain.

At the moment, it Just Works, so I'm happy.

 (And vice versa?) And then there is also MSVC...

I've never installed MSVC; I see no reason to. But apparently some
people do: more power to them.

 Of course, we cannot ever test all possible combinations. We don't do
 that on any Unix, either. But rather than listing just one or two very
 specific combinations, we can still state the options, their
 requirements, what's known to work or fail (for example the issue you
 faced with gcc 4.6.2).

I prefer to just list the one known working config; that's hard enough.
No one has ever asked for anything more (until you, now).

 FWIW, I also plan to keep my buildbot on msys 1.0, for now. While I
 don't intend to maintain the INSTALL_windows_mingw.txt document to the
 level of detail you used to do it, I'd still like to keep something in
 there that clarifies that MinGW / Msys 1.0 is known to work. Dropping
 the file, as you suggested, would lose that knowledge.

It didn't work for me, so known to work is not true, I think. It would
be best if more than one person was able to follow the install script
and succeed.

By that standard, msys2 isn't known to work, either :(.

Cygwin also didn't work for me. 

Sometimes it's just that no two Windows boxes are ever the same; it is
frustrating.

 I'll eventually write up something.

Ok.

-- 
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Stephen,

 On 05/04/2014 03:48 PM, Stephen Leake wrote:
 I just tried: There are a couple of places where Unix needs an argument
 that you've commented out. Please revert those.
 
 Done in nvm.cleanup-warnings.

 No, I still found lots crufty casts to void like this one:

 @@ -2384,6 +2457,10 @@ CMD_AUTOMATE(get_workspace_root, ,
   ,
   options::opts::none)
  {
 +  (void)execid;
 +  (void)output;
 +  (void)args;
 +
workspace work(app);
output  get_current_working_dir()  '\n';
  }

 Without explanation, lots of readers of that code, who didn't happen to
 follow this thread (or even myself in three years from now) will ask
 themselves: WTF? (See multiple instances of that on stackoverflow.)

We could add this idiom to HACKING if we keep it. But I agree it's best
to not keep the warnings enabled.

 Rather than adding even more clutter in the form of a comment about
 compiler happiness or some such, let's please just keep that warning
 disabled. It's gain-to-pain ratio is way too low.

Apparently we disagree on that. All my work projects require that warning.

 Note that we use -Wno-unused since 2006 (c1ecd781). 
 The only thing that's new is that gcc 4.8 now emits that unused
 parameter warning even though -Wno-unused is given (my gcc 4.7
 doesn't do that).

Ah; I misread that option; it's trying to _suppress_ the warnings, not
enable them.

 If you want to make an argument about enabling warnings on unused things
 in general, please try dropping the -Wno-unused and check the warnings
 that arise.

Yes, that would make sense.

 I can imagine enabling some of the currently disabled gcc warnings. The
 unused-but-set-* ones seem useful on the surface, for example. Consider
 that AC_PROG_CXX_WARNINGS doesn't currently distinguish between gcc and
 clang (3.4), though. And their set of supported options certainly
 differs slightly. I tried enabling -Wusused-but-set-variable, but clang
 doesn't understand that, for example. Also mind older versions...
 Overall, to me this just doesn't seem worth the trouble.

Ok.

 And generally speaking, there are unused things which may become useful
 at some point in time. I don't feel confident deleting all of those
 things. After all, you didn't delete the parameter name for the very
 same reason, but commented it out: You wanted to keep the name there, in
 case it becomes useful.

No, I kept it there so the implementation corresponds to the spec. 

 None the less, I also fixed a couple unused-variable and
 unused-local-typedef warnings in a9efe468. Those were obvious
 left-overs and useful hints from the compiler. But manually selected and
 checked; I intentionally left other things in there, which some compiler
 thinks are unused, but didn't seem useless to me.

Yes, g++ doesn't always get it right; that's an argument in favor of
suppressing the warning.

 I hope this still satisfies your needs and allows you to work much
 better when there are no spurious warnings.

Yes, as long as there are no warnings in the compiler output, my
workflow works :).

We should add something about this in HACKING, and perhaps suggest
compiling new code with -Wunused enabled, to catch bugs before they get
too far.

-- 
-- Stephe

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

Re: [Monotone-devel] monotone 1.1 released

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 the monotone team just released version 1.1 of its versions control
 system. 

Excellent! Thanks for your work on this.

Will you be doing the win32 installer? I can build one from an msys2 32
bit build, if needed.

-- 
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Stephen,

 On 05/03/2014 03:54 PM, Stephen Leake wrote:
 I've built nvm.msys2-mingw-64 with Mys2/MingW64 64 bit. It passes all tests
 except one func test (empty_environment) and some extra tests.

 Cool, thanks.

 What goes wrong in empty_environment? That one works on Msys 1.0.

The commit gives:

stderr:
mtn: beginning commit on branch 'testbranch'
mtn: error: sqlite error: SQL logic error or missing database

I'm guessing it's a library issue, combined with the weird way msys2
works. 

 I need to test that branch on a Unix box (I have Debian and Cygwin),
 since most of the changes are in '#ifdef Windows' areas.

 I just tried: There are a couple of places where Unix needs an argument
 that you've commented out. Please revert those.

Done in nvm.cleanup-warnings.

 Also, I'm not a fan of the cast to void hack. That clutters the source
 code quite a bit - especially when you need additional ifdefs to filter
 based on platform. I'd rather disable that warning.

I reviewed all the FIXME-UNUSED, and deleted some because they were not
needed. So -Wno-unused is useful.

There's not much clutter; I think it's worth the gain.

 Please also teach your editor to not re-indent code you didn't touch.
 That greatly eases review.

It didn't reindent, but it did remove tabs. I'll change that.

 See INSTALL_windows_msys2_64.txt for tools install; there is also
 INSTALL_windows_msys2_32.txt, which is very similar, but has 32
 instead of 64 in lots of places. Having two different files makes it
 easier to cut and paste the commands.

 I appreciate your efforts to document the build process. However, please
 keep in mind that we don't provide half the amount of instructions on
 building on any other OS. 

I think we should; there's nothing worse than trying to follow some
install instructions only to discover there is some crucial bit of
information missing.

For example, are the Botan args to configure necessary on Debian? I just
assume so (because they are required on cygwin and msys2), but I didn't
check. If I had not done the msys2 install first, I would not have known
to use them, and would have wasted time figuring that out for Debian.

What is the downside of having explicit, complete, instructions?

On the other hand, a large part of INSTALL_windows_msys2_64.txt talks
about how to install msys2. That sort of instruction is not required for
Debian and other Linux distros, because it is widely available on the
web. It is _not_ available for msys2; I had to figure it out with help
from the mailing list.

Notice that a significant portion of the messages we've exchanged are
about what tools are you using?. Having identical tool setups is
essential to tracking down bugs.

 Already before those additions, I felt the
 urge to merge, simplify and reduce the information into one file.

Why?

That will make it harder to follow, which means more likely to get it
wrong.

There are only 100 lines in INSTALL_windows_msys2_64.txt.

We could factor out the 'install msys2' part, but I don't see the point.

 I think exact commands should go into a script or on the wiki, if yo
 want. In the source tree, I'd say a single INSTALL_windows.txt showing
 different build options and outlining special considerations for Windows
 should suffice. 

I don't understand the rationale for moving stuff to the wiki. That's
harder to edit, and it won't be kept up to date. 

 As it stands, an average Windows user would need a guide on how to
 choose the correct INSTALL_windows_* file.

We are not addressing the average Windows user - that's my mom and
siblings, who read email but never compile anything.

We are addressing people who want to compile monotone. That's me and
you and a few others. I find these instructions necessary, and I'm doing
the work of maintaining them; what's the downside?

The guide is in INSTALL (just updated in nvm.msys2-mingw-64). I suggest
we delete INSTALL_windows_mingw.txt.

-- 
-- Stephe

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

Re: [Monotone-devel] Mingw 64 bit build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Stephen,

 On 05/04/2014 03:48 PM, Stephen Leake wrote:
 Done in nvm.cleanup-warnings.

 Cool, thanks. I'll have another look, soon.

 I think we should; there's nothing worse than trying to follow some
 install instructions only to discover there is some crucial bit of
 information missing.

 Yes, there is something worse than missing parts: Wrong parts. And
 out-dated stuff is pretty darn close to be wrong.

I disagree. The doc is accurate at a point in time; as long as that is
clear, people understand things change.

 The MinGW instructions prior to the recent release were helpful to some
 extent, but a lot of it was out-dated. I had to figure which parts still
 apply and which not. Granted, I didn't use the versions indicated in the
 doc. I wanted newer stuff. And I wish I had a more general, less verbose
 guide.

What would you suggest? I have no problem adding more stuff, but I
thought you wanted to reduce, not increase.

 Put another way: I just don't think we can keep up install instructions
 with that much detail for every of at least three different windoze
 build environments.

Well, I was only maintaining mingw. Now I've switched to maintaining
msys2-mingw2-32 and -64. If no one steps up to maintain the others, they
should be deleted.

 For example, are the Botan args to configure necessary on Debian?

 Depends on which version of Botan you want to compile against. Maybe you
 even want to compile against a self-compiled one in a custom location.
 We cannot possible cover all variants - nor should we.

True. And the files don't claim to.

The point is to have one known working install, for people just getting
started on a new platform. Once they get that working, they can mess
around to build it differently.

 I just
 assume so (because they are required on cygwin and msys2), but I didn't
 check. If I had not done the msys2 install first, I would not have known
 to use them, and would have wasted time figuring that out for Debian.

 Configure tells you pretty clearly if it found what it needs or what's
 missing, if it didn't. 

Yes, but it does _not_ tell you how to fix it. Why would I imagine that
I should add -I/usr/include/botan-1.10, when aptitude confirms that I
installed the botan devel package?

 Reading through pages of outdated options on how
 I don't want to do it would certainly waste much more time for me,
 thanks.

In the debian case, and in msys2, it is not pages of outdated options.
MinGW was worse, but it's obsolete now.

 On the other hand, a large part of INSTALL_windows_msys2_64.txt talks
 about how to install msys2. That sort of instruction is not required for
 Debian and other Linux distros,

 Huh? If that needs explanation, please go help the mingw or msys2
 project. 

I tried that; they are not interested. I find that many open source
projects are not interested in good docs; apparently it's less fun than
code. git is _much_ worse than monotone; it's one of the many things I
like about monotone.

 The monotone source tree clearly is the wrong place to put that
 documentation, as most users in need for it won't find it, there.

I agree that non-monotone msys2 users won't find it there. 

As a work-around until the msys2 project improves their docs, this makes
the most sense to me.

 Notice that a significant portion of the messages we've exchanged are
 about what tools are you using?. Having identical tool setups is
 essential to tracking down bugs.

 I don't think we're in the position to enforce a tool chain on your
 users. 

I'm not enforcing anything; merely documenting one known configuration
that does work.

 The best we can do is make monotone easy to compile on most
 platforms.

Yes. And easy means here are all the options I had to sweat to figure
out, so you don't have to.

I agree that doesn't help if the doc is significantly out of date (as
mingw was). I don't see how a less specific doc can be _more_ helpful.

 Instead of a lengthy document, 

100 lines is _not_ lengthy.

If you want a _lengthy_ tools install document, see
http://gds.gsfc.nasa.gov/tools_install_linux_developer.pdf (32 pages).
That's what I use for work. I would be utterly lost without it. 

 why not bundle the entire set of tools required to build monotone in a
 zip file ready to delpoy?

Because that most likely won't work as time goes by. The install docs
give enough information to catch up to new versions when necessary.

 That would save the tedious work of accurately following 100 lines of
 boring instructions.

If someone can't follow 100 lines of boring instructions to get a working
system, they are not likely to be much help to the monotone project.

Unless we do provide a tools installer, the same amount of tedious work
has to be done anyway; I don't see how it would be better to have to
also figure out each step along the way. I guess it could be more fun,
but I'd rather save my brain power for the project, not waste it on the
tools.

 I don't

Re: [Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 That being said, I certainly agree we should try to reduce compiler
 warnings as much as possible with generic ways. I started the branch
 nvm.cleanup-warnings for that work. But please keep focusing on fixing
 real issues for release 1.1, for now.

I've built nvm.cleanup-warnings with 32 bit Mys2/mingw64 (confusing
names!). I fixed all the warnings (except one that needs
nvm.msys2-mingw-64).

All tests pass on msys2, except some extra tests. I can run it on Debian
later this weekend.

synced.

-- 
-- Stephe

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

[Monotone-devel] Mingw 64 bit build

[Stephen Leake]

I've built nvm.msys2-mingw-64 with Mys2/MingW64 64 bit. It passes all tests
except one func test (empty_environment) and some extra tests.

I need to test that branch on a Unix box (I have Debian and Cygwin),
since most of the changes are in '#ifdef Windows' areas.

See INSTALL_windows_msys2_64.txt for tools install; there is also
INSTALL_windows_msys2_32.txt, which is very similar, but has 32
instead of 64 in lots of places. Having two different files makes it
easier to cut and paste the commands.

-- 
-- Stephe

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

[Monotone-devel] configure errors on 64 bit cygwin

[Stephen Leake]

I'm getting configure errors on 64 bit cygwin. I just updated cygwin.

First, I used the configure args in INSTALL_windows_cygwin.txt:

 ./configure botan_CFLAGS=-I/usr/include/botan-1.10 \
   botan_LIBS=/usr/lib/libbotan-1.10.dll.a

In config.log, that gives:

configure:5205: g++ -o conftest.exe -g -O2 -Wall -W -Wno-unused  
-I/usr/include/botan-1.10  conftest.cpp -lz  /usr/lib/libbotan-1.10.dll.a 5
g++.exe: error: /usr/lib/libbotan-1.10.dll.a: No such file or directory

So I used 

 ./configure botan_CFLAGS=-I/usr/include/botan-1.10 \
   botan_LIBS=-lbotan-1.10

That gives:

configure:5205: g++ -o conftest.exe -g -O2 -Wall -W -Wno-unused  
-I/usr/include/botan-1.10  conftest.cpp -lz  -lbotan-1.10 5
C:\tmp\ccgldZhS.o: In function `LibraryInitializer':
/usr/include/botan-1.10/botan/init.h:41: undefined reference to 
`Botan::LibraryInitializer::initialize(std::string const)'
C:\tmp\ccgldZhS.o: In function `~LibraryInitializer':
/usr/include/botan-1.10/botan/init.h:43: undefined reference to 
`Botan::LibraryInitializer::deinitialize()'
collect2.exe: error: ld returned 1 exit status


Any clues?

-- 
-- Stephe

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

Re: [Monotone-devel] configure errors on 64 bit cygwin

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 I'm getting configure errors on 64 bit cygwin. I just updated cygwin.

I have libotan-1.10.5-1

-- 
-- Stephe

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

Re: [Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 05/01/2014 09:20 PM, Markus Wanner wrote:
 You can always do `./configure CXXFLAGS=-Wno-unused-parameter` - then
 there's nothing to take out.

 Sorry, no, that doesn't work. Sigh!

 (Due to -Wunused being appended after any flags passed in, thus
 overriding that specific flag.)

Yes, configure can be a pain.

I'll just branch nvm.msys2-mingw64 from nvm.cleanup-warnings, and bypass
this issue :).

-- 
-- Stephe

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

Re: [Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 04/30/2014 10:40 AM, Stephen Leake wrote:
 I've succeeded in setting up a MinGW64 environment. It's quite nice once
 you get past the tools install issues. I have not committed
 INSTALL_windows_mingw64.txt yet; soon.

 Is is really that much different from mingw32 that it warrants a
 dedicated file? Wow!

Well, I started a separate file just in case. It turns out it is very
different; much simpler, since most of the dependent packages are
already packaged for MinGW64, and we can use 'pacman' to install them.

 In any case, please feel free to commit anything that fixes mingw-w64
 directly to nvm.

The 64 bit changes are mostly due to Windows using a different
underlying type for socket_type than Unix. There are many changes;
anything that checks for an invalid socket, some function return or
parameter types. The code is definitely cleaner after the fixes, so I
don't think it will break anything on 32 bit.
 
 I'm getting lots of 'warning: unused parameter' messages from g++:
 
 ../monotone/src/simplestring_xform.hh:51:61: warning: unused
 parameter 'thing' [-Wunused-parameter]
  origin::type get_made_fromstd::string(std::string const  thing)

 Yeah, lots of those. However, I personally postponed any such cleanup
 work for after 1.1, as it's hardly increasing stability but may possibly
 break things.

I've already done most of the work, but not commited or run the tests
yet; I'll commit it on a branch.

 Or put another way: Getting rid of warnings hasn't been a release goal
 for me.

I work much better when there are no spurious warnings; it's easier to
see the real problems in the compiler output.

So I'll add -Wno-unused-parameter to suppress the warnings, and take it
out on the branch.

-- 
-- Stephe

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

[Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

I've succeeded in setting up a MinGW64 environment. It's quite nice once
you get past the tools install issues. I have not committed
INSTALL_windows_mingw64.txt yet; soon.

I'm getting lots of 'warning: unused parameter' messages from g++:

../monotone/src/simplestring_xform.hh:51:61: warning: unused parameter 'thing' 
[-Wunused-parameter]
 origin::type get_made_fromstd::string(std::string const  thing)
 ^

The code that generates this is in simplestring_xform.hh:

template inline
origin::type get_made_fromstd::string(std::string const  thing)
{
  return origin::internal;
}

Is there a way to mark 'thing' as unused? or do we have to disable that
warning with -Wno-unused-parameter?

-- 
-- Stephe

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

Re: [Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 The code that generates this is in simplestring_xform.hh:

 template inline
 origin::type get_made_fromstd::string(std::string const  thing)
 {
   return origin::internal;
 }

 Is there a way to mark 'thing' as unused? or do we have to disable that
 warning with -Wno-unused-parameter?

I found three answers on stack overflow:

1) comment out or delete the parameter name:

a) origin::type get_made_fromstd::string(std::string const  /* thing */)

b) origin::type get_made_fromstd::string(std::string const  )

2) cast it to void:

(void)thing;

I prefer 1a; it most clearly documents that we know there is a parameter
by that name, but we are not using it in this case. Any objections?

-- 
-- Stephe

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

Re: [Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 Stephen Leake stephen_le...@stephe-leake.org writes:

 The code that generates this is in simplestring_xform.hh:

 template inline
 origin::type get_made_fromstd::string(std::string const  thing)
 {
   return origin::internal;
 }

 Is there a way to mark 'thing' as unused? or do we have to disable that
 warning with -Wno-unused-parameter?

 I found three answers on stack overflow:

 1) comment out or delete the parameter name:

 a) origin::type get_made_fromstd::string(std::string const  /* thing 
 */)

 b) origin::type get_made_fromstd::string(std::string const  )

 2) cast it to void:

 (void)thing;

 I prefer 1a; it most clearly documents that we know there is a parameter
 by that name, but we are not using it in this case. Any objections?

However, that is not appropriate in this case (command.hh):

#define CMD_NO_WORKSPACE(C, name, aliases, parent, params, abstract, \
 desc, opts) \
namespace commands { \
  class cmd_ ## C : public command   \
  {  \
  public:\
cmd_ ## C() : command(name, aliases, parent, false, false,   \
  params, abstract, desc, false, \
  options::options_type() | opts, true)  \
{}   \
virtual void exec(app_state  app,   \
  command_id const  execid, \
  args_vector const  args) const;   \
  }; \
  cmd_ ## C C ## _cmd;   \
}\
void commands::cmd_ ## C::exec(app_state  app,  \
   command_id const  execid,\
   args_vector const  args) const


In most uses of CMD_NO_WORKSPACE, execid is not used, but it is used
in some (cmd_netsync.cc clone).

So we have to use (void)exec_id in the body of each case where it is not
used.

-- 
-- Stephe

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

[Monotone-devel] sizeof int /= size of void*

[Stephen Leake]

In mingw64, pointers are 64 bit, 'int' is 32 bit. So I'm getting an
error in netxx:

../monotone/src/netxx_pipe.cc:365:31: error: cast from 'HANDLE {aka void*}' to 
'Netxx::socket_type {aka int}' loses precision [-fpermissive]
   return (Netxx::socket_type) named_pipe;

The context is:

Netxx::socket_type
Netxx::PipeStream::get_socketfd (void) const
{
#ifdef WIN32
  return (Netxx::socket_type) named_pipe;
#else
  return Netxx::socket_type(-1);
#endif
}

'socket_type' is declared in src/netxx/types.h:

/// type for representing socket file descriptors
typedef signed int socket_type;

Changing this to:

/// type for representing socket file descriptors
#ifdef WIN32
typedef HANDLE socket_type;
#else
typedef signed int socket_type;
#endif

fixes that error. There are still a couple of others, like:

  if (fd == -1)
break;


Should I commit these changes in nvm, or use a devel branch?

-- 
-- Stephe

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

Re: [Monotone-devel] 'warning: unused parameter'

[Stephen Leake]

Václav Zeman vhais...@gmail.com writes:

 You could special case GCC and introduce your own macro that expands
 to the unused attribute in case of GCC:
 http://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Attributes.html#index-g_t_0040code_007bunused_007d-attribute_002e-3000

that page says it is for functions, not function arguments.

-- 
-- Stephe

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

Re: [Monotone-devel] preparing for release 1.1

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 I'll also update my mingw install and test there.

progress report; I updated to the latest 32 bit MinGW installer, and
something is wrong. mtn compiles, and 'mtn version' works, but 'mtn
automate get_base_revision_id' crashes.

I'll try:

- MinGW64

- previous release of 32 bit MinGW

Does anyone have experience setting up a MinGW64 environment? There seem
to be many choices.

-- 
-- Stephe

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

Re: [Monotone-devel] preparing for release 1.1

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Can you run your mtn.exe from a debugger to see what's wrong (or get a
 core dump, if such a thing exists on Windows)?

I can, but the last time I investigated a bug like this it turned out to
be the compiler version, so I'd rather mess with the tools some more first.

 Does anyone have experience setting up a MinGW64 environment? There seem
 to be many choices.

 I played a bit with mingw-w64. Doesn't seem all that different to me,
 but I obviously didn't go through a complete build, yet.

 I recently updated the Windows build documentation a bit and would
 appreciate a review.

Ah. Apparently I forgot to pull/update; I thought I had done that.

It looks like you compiled Lua yourself, rather than using the MinGW
package; that may be the bug.

Since the 32 bit build is working for you, I'll work on the 64 bit version.

--
-- Stephe

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

Re: [Monotone-devel] preparing for release 1.1

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 04/27/2014 05:53 PM, Markus Wanner wrote:
 I'm just about to add a (32-bit) MinGW build slave (boar). The bot
 didn't run through all tests just yet, but that box ran through all of
 them just fine, before, so I'm surprised you're reporting such a
 problem. A smoke test of 'mtn au get_base_revision_id' seems to work
 fine for me as well.

 Oh, before I forget: The -static-lib{gcc,stdc++} options didn't work for
 me. I compiled without those (so does the build slave).

Ok. But they are still in INSTALL_windows_mingw.txt

-- 
-- Stephe

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

Re: [Monotone-devel] preparing for release 1.1

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Stephen,

 On 04/22/2014 04:45 PM, Stephen Leake wrote:
 We have always had failing tests on Cygwin (I believe). Not enough
 motivation to fix them.

 I already fixed all but one. And netsync_largish_file seems important
 enough to have a deeper look.

 My past experience with buildbot slaves is that they are much more pain
 than they are worth.

 Well, in my past experience, proper testing makes the difference between
 quality work and BS. So I use unit testing quite a lot.

I have no problem running the tests on request (although not with 1 hr
response time); I just don't think maintaining a buildbot is worth the
trouble.

 That being said, I agree that time spent to write tests vs actual code
 needs to maintain a reasonable balance. I've just disabled some tests
 that failed and which I think are beyond that balance to maintain.

And time is better spent actually running tests and fixing problems, as
opposed to fixing the buildbot infrastructure.

 Another aspect of this is that shipping tests that fail give the user a
 bad impression. Therefore, I'm rather disabling a test that's hard to
 fix and of questionable value than shipping it, knowing it's failing.

+1

I think we are violently agreeing :).

-- 
-- Stephe

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

Re: [Monotone-devel] preparing for release 1.1

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 04/18/2014 11:20 AM, Stephen Leake wrote:
 Cygwin now comes in two flavors; 32 bit and 64 bit; which are you using?
 I have Cygwin 64; I'll see if I can compile monotone on that.

 I tested on Cygwin 64. However, I'd expect the provided versions of
 dependent libraries to be the same, so most of the INSTALL document for
 cygwin should be the same. But yeah, we should clarify that.

 As evident from the buildbot, cygwin currently fails on some tests,
 which I consider a release blocker.

We have always had failing tests on Cygwin (I believe). Not enough
motivation to fix them.

 Can you possibly provide a buildbot slave?

My past experience with buildbot slaves is that they are much more pain
than they are worth.

-- 
-- Stephe

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

Re: [Monotone-devel] preparing for release 1.1

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 I finally got around cleaning up things for a 1.1 release.

Thanks for working on this

 I updated the UPGRADE, NEWS and INSTALL documents a bit. Please
 review.

Cygwin now comes in two flavors; 32 bit and 64 bit; which are you using?
I have Cygwin 64; I'll see if I can compile monotone on that.

I'll also update my mingw install and test there.

That will probably take me a couple of weeks.

-- 
-- Stephe

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

Re: [Monotone-devel] release 1.1 - status

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 02/02/2014 11:17 PM, Stephen Leake wrote:
 Although it appears we should switch to MinGW-w64, I think that can
 wait for the next release.

 Does switch here refer to the build we provide? 

Yes.

 Or does it imply we
 have compilation issues, there? Did you test MinGW-64?

I have not tested with MinGW-64; I have not even installed it yet. I'm
just reporting that I've heard other projects are switching to MinGW-64,
because it supports 64 and 32 bit Windows, while MinGW 32 only supports
32 bit Windows.

I'll get to it sometime, but certainly not for a 1.1 release.

-- 
-- Stephe

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

Re: [Monotone-devel] release 1.1 - status

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 I'm still interested in compiling a release.

Thanks for working on this.

 To my current knowledge, we are doing fine on Debian and Cygwin,

Windows (Mingw 32) is also fine. 

Although it appears we should switch to MinGW-w64, I think that can
wait for the next release.

 but currently have issues on FreeBSD (10, at least) as well as OSX.

Sorry, I can't help with those.

--
-- Stephe

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

Re: [Monotone-devel] [Monotone-users] CAD versioning

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 On Thu, Dec 12, 2013 at 11:44:51AM -0600, Stephen Leake wrote:
 Roberto Bartola robertobart...@gmail.com writes:
 
  I'm looking for a versionig software which could be used in (M)CAD 
  projects.
  I such projects we can find many parts assembled in assemblies and
  sub/assemblies.
  I'd like to understand if is it possible to checkin/checkout and put in a
  lock way the assemblies with its component.
 
 It is certainly possible to commit the files to monotone; it can handle
 any files.

 Monotone can certainly store any files; but can it merge changes to 
 those files?

If not, you can specify an external merge tools. Or use a front-end that
supports other merge tools.

If there isn't a merge tool for your file format, then that's a problem.

The typical solution to not being able to merge files is to forbid
parallel editing. The OP did mention locking, which is one technique
to enforce a no parallel editing policy. 

monotone does _not_ support locking. locking requires a central
repository, at least for the locks; monotone is specifically designed to
_not_ require a central repository.

Other CM systems, that are _not_ distributed, do support locking.

-- 
-- Stephe

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

Re: [Monotone-devel] [Monotone-users] CAD versioning

[Stephen Leake]

Roberto Bartola robertobart...@gmail.com writes:

 I'm looking for a versionig software which could be used in (M)CAD projects.
 I such projects we can find many parts assembled in assemblies and
 sub/assemblies.
 I'd like to understand if is it possible to checkin/checkout and put in a
 lock way the assemblies with its component.

It is certainly possible to commit the files to monotone; it can handle
any files.

 To do it I need the version software could understand the CAD
 assemblies or (may be easier) the version software read in a txt file
 the way the components are assembled.

I don't understand why you think mtn would need to understand the
assemblies. What work flow would this enable?

It is certainly possible for mtn to store a text file that the CAD
system uses.

 Is it possible using MONOTONE?

Yes, but it sounds like you need help with your desired workflow. You
may find it helpful to write some Lua or shell scripts to enforce some
higher level rules, or make things simpler.

If you can write up a simple example of how you see using a tool like
mtn, we could help.

-- 
-- Stephe

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

Re: [Monotone-devel] Thanks. Re: nested workspaces

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 But it's better to checkout the two projects in parallel; there's no
 reason the directory structure has to match the main/sub project
 structure.

 Well, actually, there is.

 I'm writing stories.  Some are short, some are long and end up 
 organised into many files.  Each story, once it's well-enough conceived 
 to be considered a story, ends up being a separate (sub)project.

Ok.

 But there's also prewriting, where ideas and text fragments are thrown 
 about long before there's any pretense of them being stories.  These 
 get looked through now and then, and sometimes they, in various 
 combinations, become stories of their own.  Whrn that happens, I make a 
 subdirectory to isolate them from the general chaos and make a 
 concentrated place to work on them.

Why is that new directory under some other story, rather than at the
stories root level?

 So each story's main directory is checked into a monotone branch of its 
 own, so its further revision history doesn't get mixed with the 
 completely different revision history of other, irrelevant stories.

Right. So why are new ones not like that?

 But the main directory, that contains all these subproject workspaces, 
 is where all the initial inchoate thoughts are conceived and stored, as 
 well as README files explaining the organisation that does exist, and 
 various scripts that manage the whole  thing.

The directory for inchoate thoughts should be in parallel to the
stand-alone stories:

stories

inchoate

story_1

story_2

 And it's all wrapped up in one big directory for convenience, to 
 separate it from other things that have nothing to do with story 
 writing.

See above; no problem

 The main directory is the natural place to put the idea soup that 
 hasn't crystallized into specific projects yet.

That's not natural to me. 

But I'm glad monotone can work for you :).

-- 
-- Stephe

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

Re: [Monotone-devel] nested workspaces

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 I've never found a clear discription of what happens with nested workspaces.
 Maybe I just haven't looked enough.

 For example, I may have a project and a subproject.

 I checkout the project, and get a directory fill of stuff, including a 
 _MTN directory.

 Subsequently cd into that and check out another project into a new 
 directory I'll call subproject.  It too has a _MTN directory.

 How do these two interact.

badly. But there is a simple workaround; see below.

 I presume that when I'm in the subproject directory, monotone will see 
 just the subproject.

Yes; it looks for _MTN to indicate the project root.

 But when I'm in the main  project, to what extent is monotone aware of 
 the subproject?  

All files/directories in the subproject will appear as 'unknown' to the
main project.

 When doing things like mtn list known, does it see the _MTN file of
 the subproject as a warning not to go there?

No.

 Or can I take files that are part of the subproject and add them into 
 the main project as well, so that both monotones apply updates to the 
 same file?

You can, but that will be confusing. If you commit a changed file to the
subproject, the file will still appear changed to the main project.

 Or can I even go so far as to put the _MTN directories of the 
 subproject under revision control as part of the main workspace? (I 
 suspect this is a bad idea; I'm interested in just what the limits 
 are).

It is a bad idea, because the _MTN/options file contains absolute paths
that are valid for your machine, but probably invalid for others using
the project.

The _MTN/revision file changes with each commit.

 Or what?

The workaround is to put the subproject root directory in .mtn-ignore
for the main project. .mtn-ignore should then be committed in the main
project, which means it has knowledge of the subprojects, reducing
independence. 

But it's better to checkout the two projects in parallel; there's no
reason the directory structure has to match the main/sub project
structure.

 I'm thinking of using this in a context where the subprojects are 
 really independent projects in their own right, 

Ok.

 but the main project contains their workspaces, 

This suggests you are using the term workspace differently than mtn
does. In mtn, it means the directory tree checked out from one mtn
branch. And project means a set of related branches in a mtn
repository (more than one branch for parallel development), although
that's less well-defined. A project never contains a workspace; a
workspace is an instance of a project. Which is sort of what you
described above, I'm just verifying the terminology.

If you check out the main and sub as described above, the correct mtn
description is the main workspace contains the sub workspaces. If you
put the sub workspaces in the main .mtn-ignore, then the main project
does not contain the sub project. 

Why do you want to do this? What problem does it solve? 

One thing it enables is find from the main project root. But if you
check out the main project and subproject as sibling directories in the
same super-root, you can still do that. That's what I do for my related
mtn projects. 

Another thing to consider is relative paths in main project Makefiles
etc that refer to the subproject. They depend on exactly where the
subproject is checked out. Nothing in the setup you've described
_enforces_ where the subproject is checked out; other developers might
ignore the policy and check them out as siblings, breaking the Makefile.

A fix for that is to write Lua code to unify checking out and updating
the related projects. That way, the relative paths in Makefiles etc are
enforced by the Lua scripts. That can enforce checking out the
subproject as either a sub or sibling directory. I do that for my
related projects (as sibling directories); if you'd like to see the Lua
code, let me know.

Another thing to consider is the branching policy, and the workspace
directory naming policy. Are there developer branches for all the
projects, or only for the main project? How are the workspaces named?
How does that affect relative paths?

I normally name the workspace directory to indicate the mtn branch it is
checked out from; that can break relative paths if the projects are not
all branched together.

I always branch all the related projects together, so I can safely
modify _any_ of the code to fix something. But some code really is
changed rarely, so other branching policies might make sense.

 documentation files that organize the collection, and other files that
 may or may not later become projects in their own right.

All of those can stay in the main project; this is orthogonal to the
issue of where to check out the files.

It does mean the main project is aware of the subprojects, so putting the
subprojects in the main project .mtn-ignore is more acceptable.

 Assuming this model is feasible, of course.

It is, with the 

Re: [Monotone-devel] Forbid a changeset from merging

[Stephen Leake]

Hendrik Boom hend...@topoi.pooq.com writes:

 Is there any way to mark this one changeset so that it will never be 
 merged into the main branch?

This is not possible with the current monotone. 

It has come up in other contexts; the Emacs developers would like the
capability. (If we implement it, they just might switch to monotone :).

You could do it manually with the following steps:

- generate a diff file containing the changeset.

- propagate from local to main

- apply the diff in reverse

- commit on main.


That leaves one bad revision in main, but otherwise it's not too bad.

It should be possible to do this internally, avoiding the bad
revision. But it will break if the diff fails to apply. In that case,
you need to regenerate the diff somehow; maybe start a new local branch
from main, add the new local config.

We'd need a way to identify the changeset to revert; from/to rev ids
would work. Then you can specify those revids in an option to the
propagate command.

Or the diff could just be in a file, not derived internally from the
revision history. Then you could fix it when it breaks; that seems
simpler. It could still be applied internally before committing the new
revision in propagate.

Hmm. It might be necessary to have propagate apply the diff forward when
propagating from main to local again; I'm not clear on that.

-- 
-- Stephe

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

Re: [Monotone-devel] recent Botan changes?

[Stephen Leake]

Richard Hopkins richhguard-monot...@yahoo.co.uk writes:

 How recent a head?

 I've done a fresh checkout of
 083dfa48871b21905f81ab22822709e0db97635b: autoreconf, configure, make
 cycle with no problems using botan 1.6.4.

 5934509c86e975ce771c66a1511671620eceb6d0 is fine as well which I was
 at previously and is a child of 9ff6e4 (introduced the new botan
 defines).

 I haven't tested those yet on OpenSUSE/Windows with the later botan versions.

Ok. I'll put it down to a misconfigure on Red Hat.

-- 
-- Stephe

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

[Monotone-devel] recent Botan changes?

[Stephen Leake]

I'm compiling monotone head on Red Hat 5.0 (for work); I need a recent
fix I put in for drop/modified conflicts. 

The Red Hat repository does not have Botan (any version).

Until very recently, monotone compiled with Botan 1.8.13. Then some
change (I have not tried to narrow it down) caused this error:

if g++  -I. -I../monotone.main -I.
-I/home/stephe/Projects/boost_1_46_1  -g -O2 -Wall -W -Wno-unused -MT 
src/database.o -MD -MP -MF $depbase.Tpo -c -o src/database.o 
../monotone.main/src/database.cc; \
then mv -f $depbase.Tpo $depbase.Po; else rm -f $depbase.Tpo; 
exit 1; fi
../monotone.main/src/database.cc:226: warning: ‘database_impl’ has a field 
‘database_impl::statement_cache’ whose type uses the anonymous namespace
../monotone.main/src/database.cc:226: warning: ‘database_impl’ has a field 
‘database_impl::roster_cache’ whose type uses the anonymous namespace
../monotone.main/src/database.cc:226: warning: ‘database_impl’ has a field 
‘database_impl::vcache’ whose type uses the anonymous namespace
../monotone.main/src/database.cc: In member function ‘void 
database::encrypt_rsa(const key_id, const std::string, rsa_oaep_sha_data)’:
../monotone.main/src/database.cc:3444: error: no matching function for call to 
‘Botan::PK_Encryptor_MR_with_EME::PK_Encryptor_MR_with_EME(Botan::RSA_PublicKey,
 const char [12])’
/usr/include/botan/pubkey.h:305: note: candidates are: 
Botan::PK_Encryptor_MR_with_EME::PK_Encryptor_MR_with_EME(const 
Botan::PK_Encryptor_MR_with_EME)
/usr/include/botan/pubkey.h:301: note: 
Botan::PK_Encryptor_MR_with_EME::PK_Encryptor_MR_with_EME(const 
Botan::PK_Encrypting_Key, Botan::EME*)
make: *** [src/database.o] Error 1

I tried upgrading to Botan 1.10.5 (current as of today), but that fails
at configure time with a Python syntax error. Red Hat 5.0 has Python
2.4.3, Botan 10.x apparently requires a later Python version.

On Windows at home, I have Python 2.7, Botan 1.10.1; that works with
monotone head.

monotone configure says we support Botan  1.6.3, which is apparently
no longer true.

I did not try installing a newer Python from source on Red Hat; I'll do
that tomorrow (actually later today, now :).

I haven't checked what version of Botan is current on Debian; my Debian
box is not cooperating at the moment (I haven't turned it on in quite a
while).

-- 
-- Stephe

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

Re: [Monotone-devel] recent Botan changes?

[Stephen Leake]

Richard Hopkins richhguard-monot...@yahoo.co.uk writes:

 monotone configure says we support Botan  1.6.3, which is apparently
 no longer true.

 We should fix this then.

 I successfully compile and run monotone (head) with botan 1.6.4 on
 SUSE Enterprise, and from memory 1.8.x and 1.10.x on OpenSUSE/Windows.

How recent a head?

This is the revision that failed for me:

   7282e7ba458b5e92f9c3850486c7b1c0df13c951
   2013-03-20T11:53:14  stephen_leak...@stephe-leake.org
 * src/merge_content.cc (get_dropped_details): replace rev_id with 
uncommon_ancestors, lca; much more efficient search

I'm guessing the problem is introduced in:

   9ff6e41adc6f40ae054fb4487f356bf69324dbdb
   2013-03-17T10:14:12  mar...@bluegap.ch
 Add conditional code using Botan 1.10 specific API. This prevents

Maybe my actual problem is that the condition #defines are not set
properly on my Red Hat system when using Botan 1.8.3; I did not
investigate.

-- 
-- Stephe

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

Re: [Monotone-devel] recent Botan changes?

[Stephen Leake]

Thomas Moschny thomas.mosc...@gmx.de writes:

 Am Tue, 26 Mar 2013 03:59:42 -0400
 schrieb Stephen Leake stephen_le...@stephe-leake.org:

 I'm compiling monotone head on Red Hat 5.0 (for work); I need a recent
 fix I put in for drop/modified conflicts.

 The Red Hat repository does not have Botan (any version).

 Botan is available for RHEL 5 and 6 via the EPEL[1] repository.

I'm using the official supported Red Hat at work; we have a
maintenance contract.

I'm not clear how to go about telling the system to add another
repository to search, and I'm not sure what that would do to the
maintenance contract; for now, it's easier to install stuff from source.
It goes in /usr/local, so it's easy to distinguish from the official
stuff.

 I tried upgrading to Botan 1.10.5 (current as of today), but that
 fails at configure time with a Python syntax error. Red Hat 5.0 has
 Python 2.4.3, Botan 10.x apparently requires a later Python version.

 Python 2.6.X is also available via EPEL, should be easier to try that
 instead of compiling from sources.

I did some more work today; Python 3.3.0 and 2.7.3 both compiled easily
from source.

Then Botan 1.10.5 compiled easily as well, except that configure.py only
works with 2.7.3.

I had to add -I/usr/local/include/botan/botan-1.10 and -lbotan-1.10 to
the mtn configure line, then it compiled fine. and it works, so I'm happy.

 monotone configure says we support Botan  1.6.3, which is apparently
 no longer true.

 We should fix this then.

Yes. But what range of Botan versions do we want to support? I'm ok with
1.10, but Debian stable is also an important consideration.


 BTW, do you think it makes sense to backport the fix you mentioned to
 0.42, the Monotone version provided via EPEL for RHEL5?

no, 0.42 doesn't support mtn conflicts at all.

Who's maintaining mtn in that repository?

--
-- Stephe

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

Re: [Monotone-devel] boost 1.53 breaks monotone build

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 On 03/19/2013 05:11 AM, Stephen Leake wrote:
 This has *i after erase (i), which can have random effects depending on
 the stack/heap content.

 Good catch.

Thanks.

Of course, I'm the one that wrote the bad code in the first place :(.

-- 
-- Stephe

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

Re: [Monotone-devel] ***SPAM*** Re: About certs

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

 Le Fri, 07 Dec 2012 06:54:17 -0500,
 Stephen Leake stephen_le...@stephe-leake.org a écrit :

 Frédéric Praca frederic.pr...@free.fr writes:
 
  Ok, forget it, it does not seem to be relevant.
 
 For automate, ok
 
  I close the ticket as won't fix.
 
 no, the non-automate needs to be fixed
 Well, it's maybe better to re-open one ticket with only the commands
 that don't support it instead of modifying the ticket #218.

There's no standard policy, but I don't see any reason for a new ticket;
we just need to state clearly what the resolution is.

 For the moment, I've just seen 'ls certs' but there can be others.

It would be nice to catch everything, but it's more important to fix the
ones we know about.

 Moreover, I didn't write the unit test. Where should it reside ? I
 have only found test/func/date_formatting that could be related to
 such issues. Do I have to create another one specifically for this
 issue ?

Adding a test of ls certs to that test makes sense.

 Concerning unit tests, I have one question. How do you run only one
 test in the framework Monotone uses ?

cd .../monotone-build_mingw/
./run_func_tests -d test name

the test name is matched against all the tests, so:

./run_func_tests -d date_formatting

will run just that test,

./run_func_tests -d db_

will run all tests starting with db_

-- 
-- Stephe

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

Re: [Monotone-devel] ***SPAM*** Re: About certs

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

 Ok, forget it, it does not seem to be relevant.

For automate, ok

 I close the ticket as won't fix.

no, the non-automate needs to be fixed

-- 
-- Stephe

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

Re: [Monotone-devel] ***SPAM*** Re: About certs

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

 Second, automate output should _not_ be formatted; it is not intended
 to be seen by the user, but parsed by a tool that then presents it to
 the user. The tool expects the default formatting, and should not
 have to cope with random user settings.

 So my bug was not a bug so we should maybe revert it.

 In fact, I wrote after creating the Ohloh binding to Monotone which
 required to provide the timezone in the date output. I just added a
 +00:00 by hand as a workaround.

 But I think that we loose the timezone information when using automate.

Hmm. What timezone are you looking for? There is none stored in the
database; all dates are UTC. I can think of at least two that might be
relevant:

1) the timezone active at the time automate is run

get that outside automate; why would this be useful?

2) the timezone active when the commit was made

not stored anywhere; why would this be useful?

Is there another timezone you want?

 So, adding date format allowed the tool that parse output to provide
 the date format is waiting for but you're right, if the tool does not
 provide the option, it will rely on user settings which is wrong.

Well, your tool is adding the format parameter, so all is ok for
your tool. The problem is other tools, that don't add the format
parameter.

I don't think there is a way in monotone to tell if an option is
specified on the current command line, or elsewhere (in some .monotonerc
file). If there was, we could only use a date format when specified
directly with the automate command.

-- 
-- Stephe

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

Re: [Monotone-devel] ***SPAM*** Re: About certs

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

 So, yes, there's something to review but just a bugfix :)

What is the name of the branch? There are a lot, so it's easy to miss a
new one.

-- 
-- Stephe

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

Re: [Monotone-devel] Purpose of origin_aware

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

 Hello guys,
 I would like what is the purpose of the origin_aware class.

It allows distinguishing between user input and internally generated
items (usually strings). This sometimes changes behavior (ie error vs
warning), or just the text of error messages.

-- 
-- Stephe

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

Re: [Monotone-devel] ***SPAM*** About certs

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

 Now that I have a version that can handle standard local manipulation
 (db init, setup, co, ci, merge), I have a problem when syncing two
 databases. I received a message telling that the database is too old.

What was the exact message?

 What happens when syncing ?

Lots of stuff :). Try 'mtn -v sync' to see some of it.

 Moreover, I would like to know where can I find documentation on
 netsync.

The user guide gives a top level view. The source code is the best place
for details, but it can be very confusing.

-- 
-- Stephe

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

Re: [Monotone-devel] About certs

[Stephen Leake]

Frédéric Praca frederic.pr...@free.fr writes:

  Moreover, I would like to know where can I find documentation on
  netsync.
 
 The user guide gives a top level view. The source code is the best
 place for details, but it can be very confusing.
 Well, that's what I thought. If it's as confusing as what I've aready
 seen, it will be ok and I don't think it's that confusing ;)

Ok, have fun :).

 I did not try but I put my public monotone key on the forge, will it be
 enough to commit a new branch with my certs development for review or do
 I have to provide it to someone else ?

After committing a branch to your local database, you must sync with the
central db (it appears you know this, I'm just being sure).

Then post here, so people know there is something to review.

-- 
-- Stephe

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

Re: [Monotone-devel] date selectors using local time for comparison (Stephen Leake)

[Stephen Leake]

Richard Hopkins richhguard-monot...@yahoo.co.uk writes:

 Hm. The tests must set some env variable so all times are UTC; that
 would be required for consistency, with testers in several time
 zones. But we should have at least one test that sets a different
 time zone, to test stuff like this.
 
 Agree. Any ideas how we would do that?

In my bash shell, there's an environment variable TZ, set to
America/New York. I assume that controls the time zone.

I just grepped for TZ in monotone/test/; this one looks promising:

./src/testlib.lua:912:  set_env(TZ, UTC)

and this:

./func/date_formatting/__driver__.lua:17:  set_env(TZ, tz)

(There were a _lot_ of false grep hits on TZ occuring in mtn packet data!)


Searching at ask.com for TZ environment variable turned up this:

http://en.wikipedia.org/wiki/List_of_tz_zones_by_name

-- 
-- Stephe

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

Re: [Monotone-devel] date selectors using local time for comparison

[Stephen Leake]

Richard Hopkins richhguard-monot...@yahoo.co.uk writes:

 I've run into an issue recently using the date selectors, try this

 $ mtn db init --db=test.db
 $ echo hello  test.txt
 $ mtn add test.txt
 $ mtn commit
 $ mtn log -rl:5 minutes ago

 I would expect to see revision I've just committed, however, nothing
 will be matched. The database shows the dates being in UTC (using
 sqlite3).

That's bad; the user input time should be converted to UTC before being
compared. I thought it was, back when this was added.

 Changing the query to

 $ mtn log -rl:65 minutes ago

 returns the commit because in the UK we are currently 1 hour ahead of UTC.

 What I'm confused about though is that adding the 5 minutes ago test
 to check_later_and_earlier_selectors returns the correct revisions;
 in a separate terminal it returns nothing.

Hm. The tests must set some env variable so all times are UTC; that
would be required for consistency, with testers in several time zones.
But we should have at least one test that sets a different time zone, to
test stuff like this.

-- 
-- Stephe

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

Re: [Monotone-devel] monotone 1.1 release thoughts

[Stephen Leake]

richhguard-monot...@yahoo.co.uk writes:

 Does anyone have any thoughts on releasing monotone 1.1?

Yes I think it's time. I've fixed all the bugs I feel need fixing.

 My vote is to release it soon, maybe christmas? 

I think we can be more ambitious than that :).


-- 
-- Stephe

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

Re: [Monotone-devel] `mtn cat` garbling Windows newlines

[Stephen Leake]

richhguard-monot...@yahoo.co.uk writes:

 [Stephe]
 The problem does seem to be cmd_files.cc dump_file. It needs
 to write a
 file_data object to a std::ostream. What function would you
 recommend
 instead of ''?

 I did manage to get something compiled that passed the test on Linux
 but can't find it now. It was something involving (), c_str() and
 val() on the 'dat' variable (not sure about that one, might have been
 dat()). I didn't commit it in case someone better at C++ had a better
 way.

This compiles:

  string const dat_string = dat.inner()(); // FIXME: debugging
  output.write (dat_string.c_str(), dat.inner()().length());

(The dat_string temp var is not needed; it just aids debugging. It
should be deleted to avoid an extra copy)

But it still puts in the extra 0x0d:

stephe@takver$ dump numbers
numbers:
  310d 0a32 0d0a  1..2..
stephe@takver$ dump stdout
stdout:
  310d 0d0a 320d 0d0a 1...2...

Running in the debugger, I can see that the extra 0x0d is comming from
write (or something after it); dat_string contains:

(gdb) x /6xb 0x674555c
0x674555c:  0x310x0d0x0a0x320x0d0x0a

On the other hand, mtn automate get_file_of also uses dump_file, but it
passes (with the original dump_file):

check(mtn(automate, get_file_of, numbers), 0, true, false)
check(samefile(stdout,  numbers))

So the problem is in the output stream, not in dump_file. 'mtn cat' uses
cout, 'mtn automate' uses something else (but I thought it eventually
uses cout; I didn't try to find it).

Since 'mtn automate get_file_of' is just as easy to use as 'mtn cat', I
suggest we document this, and leave it.

It's probably worth keeping the cat_does_not_alter_newlines test, with
an xfail, and the above check on get_file_of. That way, if something
changes, we'll know to update the documentation.

-- 
-- Stephe

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

Re: [Monotone-devel] netsync over ssh revisited

[Stephen Leake]

Richard Levitte rich...@levitte.org writes:

 stephen_leake I'd have to see a list of all the protocols mtn supports to 
 try to come
 stephen_leake up with a reasonable classification. Which is what your manual 
 update
 stephen_leake will provide, so I think that's the place to start.

 mtn:(netsync via tcp)
 file:   (netsync via --stdio)
 ssh:(which is basically file: tunneled through ssh)
 ssh+ux: (Unix domain socket via ssh)
 local:  (kind sorta supported, it's supported by netxx and can be used
  as a argument to --bind, and is the way a server should be
  set up to be accessible via ssh+ux:)

plus proposed ssh+local: (ssh + tcp socket)

I don't see much of a pattern here, no need to rename ssh+ux

-- 
-- Stephe

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

Re: [Monotone-devel] netsync over ssh revisited

[Stephen Leake]

Richard Levitte rich...@levitte.org writes:

 In message 20120906.055612.470427758.rich...@levitte.org on Thu, 06
 Sep 2012 05:56:12 +0200 (CEST), Richard Levitte rich...@levitte.org
 said:

 richard I had a look in std_hooks.lua and noticed the ssh+ux: schema, which
 richard basically does what I'm after...

 Speaking of this, I'm thinking about that scheme name, and it comes
 out as odd to me...  there seems to be a concensus out there that a
 protocol transported through another protocol should be named
 {protocol}+{transport}.  ssh+ux: does the exact opposite, and ux+ssh:
 would be more appropriate.  Furthermore, since that's basically UNIX
 domain sockets piped through SSH, and mtn supports local UNIX domain
 sockets through the scheme local: (because netxx does that, that's
 why), I'm pondering that the ssh+ux: scheme should really be renamed
 to local+ssh: (of course, we can keep ssh+ux: as an alias).

 Thoughts?

local+ssh sounds more like your second scheme

Attempting to generalize/abstract a naming convention:

ssh {host} socat - UNIX-CONNECT:{path}

I'm not clear what's a protocol and what's a transport here; it seems to
me the actual data exchange protocol is always mtn (that defines how to
exchange certs, keys, revisions, and possibly authentication), and both
ssh and unix domain sockets are transports.

This connects to a running remote multi-session server; other choices
start a single session server.

ssh {host} socat - TCP-CONNECT:localhost:4691

here we have ssh and tcp sockets as transport, and it connects to a
running remote multi-session server

other choices:

mtn:

tcp sockets as transport, connects to a running remote multi-session server

perhaps this should just be named tcp? 

file:

unix domain sockets as transport, start a single-session local server.

ssh:

ssh as transport, start a single-session remote server

 Either way, I realised that the possible uris aren't fully documented
 in the manual, so I'm doing so now.  

That's good.

 And I think it would be good to have a consensus on local+ssh: vs
 ux+ssh: vs ssh+ux: before the added documentation gets published.

Now is the time to rename it, if we are going to. But so far, I don't
see a clear naming convention. 


This discussion suggests a way to make file: work on Windows native; use
TCP sockets to connect between the client and server instances of mtn.

-- 
-- Stephe

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

Re: [Monotone-devel] file: on windows via tcp sockets

[Stephen Leake]

Richard Levitte rich...@levitte.org writes:

 04:56:45 -0400, Stephen Leake stephen_le...@stephe-leake.org said:

 stephen_leake This discussion suggests a way to make file: work on Windows 
 native; use
 stephen_leake TCP sockets to connect between the client and server instances 
 of mtn.

 Not sure that's a good idea from a security point of view.

Hmm. We start the client, which starts the server process, giving it a
random port to wait on. The server process then waits for the client to
do a socket connect, on that port.

I guess the security issue is that some hacker could notice the port and
connect to it? We could use the mtn authentication to avoid that.

There will be Windows Firewall issues; it will prompt the user about
allowing internet connectivity for what they think is a purely local program.

-- 
-- Stephe

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

Re: [Monotone-devel] netsync over ssh revisited

[Stephen Leake]

Richard Levitte rich...@levitte.org writes:

 In message 858vcnil6a@stephe-leake.org on Thu, 06 Sep 2012
 04:56:45 -0400, Stephen Leake stephen_le...@stephe-leake.org said:

 stephen_leake Attempting to generalize/abstract a naming convention:
 stephen_leake 
 stephen_leake ssh {host} socat - UNIX-CONNECT:{path}
 stephen_leake 
 stephen_leake I'm not clear what's a protocol and what's a transport here; 
 it seems to
 stephen_leake me the actual data exchange protocol is always mtn (that 
 defines how to
 stephen_leake exchange certs, keys, revisions, and possibly authentication), 
 and both
 stephen_leake ssh and unix domain sockets are transports.

 You're right, it was poorly expressed.  Say {transpport}+{tunnel} 

The Unix domain socket is not tunneling the ssh transport; socat is
bridging the two transports.

I'd have to see a list of all the protocols mtn supports to try to come
up with a reasonable classification. Which is what your manual update
will provide, so I think that's the place to start.

-- 
-- Stephe

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

Re: [Monotone-devel] netsync over ssh revisited

[Stephen Leake]

Richard Levitte rich...@levitte.org writes:

 So I wonder, has anyone else already played with having netsync
 tunneled over ssh but otherwise working exactly like the usual mtn:
 schema?  (in other words, it still requires a mtn running as server on
 the remote end)

I have not tried it, but you can probably get there with ssh port forwarding.

 My other question is, is there any reason why monotone shouldn't
 support that?  A mtn+ssh: schema, say?  Technically, it shouldn't be
 harder than supporting the current ssh: schema.

There was discussion of using ssl, a while back.

-- 
-- Stephe

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

Re: [Monotone-devel] Updated Issue 212 - sync needs list of include patterns (monotone)

[Stephen Leake]

c...@monotone.ca writes:

 Hello,

 The following issue has been updated:

 212 - sync needs list of include patterns
 Project: monotone
 Status: New
 Reported by: Stephen Leake
 URL: https://code.monotone.ca/p/monotone/issues/212/
 Labels:
  Type:Feature Request
  Priority:Medium

 Comments (last first):

 # By Stephen Leake, Aug 25, 2012:

 The pre-1.0 sync syntax allowed multiple include patterns (multiple
 GLOBs) and multiple exclude patterns (--exclude options). The 1.0 URI
 syntax only allows one include pattern.


It turns out this is not true; the code supports multiple include
patterns, but the user manual says (in the URI syntax) that it does not.

I added a unit test in monotone/test/unit/tests/uri.cc that demonstrates
this:

  test_one_uri(mtn://venge.net/monotone?include1;-exclude1;-exclude2;include2,
   mtn, , venge.net, , /monotone, {include1,include2}, 
{exclude1,exclude2});

In the user manual, the URI syntax is described as:

scheme://[[user@@]host[:port]][/path][?pattern[;-exclude-pattern[...]]]

That says there is only one include pattern, but multiple exclude
patterns. The examples only show one include and one exclude.

I suggest we change it to this:

scheme://[[user@@]host[:port]][/path][?include-pattern[;include-or-exclude-pattern]...]

Branches matching a pattern are excluded if the pattern starts with
'-', included otherwise.

...
mtn://my.server/project?one.branch;-one.branch.test;another.branch;-another.branch.test
...


Comments?

-- 
-- Stephe

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

Re: [Monotone-devel] Updated Issue 212 - sync needs list of include patterns (monotone)

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 c...@monotone.ca writes:

 Hello,

 The following issue has been updated:

 212 - sync needs list of include patterns
 Project: monotone
 Status: New
 Reported by: Stephen Leake
 URL: https://code.monotone.ca/p/monotone/issues/212/
 Labels:
  Type:Feature Request
  Priority:Medium

 Comments (last first):

 # By Stephen Leake, Aug 25, 2012:

 The pre-1.0 sync syntax allowed multiple include patterns (multiple
 GLOBs) and multiple exclude patterns (--exclude options). The 1.0 URI
 syntax only allows one include pattern.


 It turns out this is not true; the code supports multiple include
 patterns, but the user manual says (in the URI syntax) that it does not.

 I added a unit test in monotone/test/unit/tests/uri.cc that demonstrates
 this:

   
 test_one_uri(mtn://venge.net/monotone?include1;-exclude1;-exclude2;include2,
mtn, , venge.net, , /monotone, 
 {include1,include2}, {exclude1,exclude2});

 In the user manual, the URI syntax is described as:

 scheme://[[user@@]host[:port]][/path][?pattern[;-exclude-pattern[...]]]

 That says there is only one include pattern, but multiple exclude
 patterns. The examples only show one include and one exclude.

 I suggest we change it to this:

 scheme://[[user@@]host[:port]][/path][?include-pattern[;include-or-exclude-pattern]...]

Actually, the first pattern can also be an exclude. So a simpler syntax
is this:

scheme://[[user@@]host[:port]][/path][?pattern[;pattern]...]

Branches matching a pattern are excluded if the pattern starts with
'-', included otherwise.

-- 
-- Stephe

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

Re: [Monotone-devel] Updated Issue 212 - sync needs list of include patterns (monotone)

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 In the user manual, the URI syntax is described as:

 scheme://[[user@@]host[:port]][/path][?pattern[;-exclude-pattern[...]]]

 That says there is only one include pattern, but multiple exclude
 patterns. The examples only show one include and one exclude.

 I suggest we change it to this:

 scheme://[[user@@]host[:port]][/path][?include-pattern[;include-or-exclude-pattern]...]

 Actually, the first pattern can also be an exclude. So a simpler syntax
 is this:

 scheme://[[user@@]host[:port]][/path][?pattern[;pattern]...]

 Branches matching a pattern are excluded if the pattern starts with
 '-', included otherwise.

One more try:

scheme://[[user@@]host[:port]][/path][?[-]pattern[;[-]pattern]...]
Branches matching a pattern are excluded if the pattern is preceded by
'-', included otherwise.

-- 
-- Stephe

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

Re: [Monotone-devel] Updated Issue 212 - sync needs list of include patterns (monotone)

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 I added a unit test in monotone/test/unit/tests/uri.cc that demonstrates
 this:

   
 test_one_uri(mtn://venge.net/monotone?include1;-exclude1;-exclude2;include2,
mtn, , venge.net, , /monotone,
{include1,include2}, {exclude1,exclude2});

Arg. I forgot that you have to compile unit_tester.exe in order to run a
new unit test; this test fails.

And it would not prove this works; it's only testing the URI parsing at
a lexical level; the query is 'include1;-exclude1;-exclude2;include2'.

So I added a lua test, which does show that it works (not commited yet):

check(mtn2(pull, srv.url .. ?-branch1;branch2;-branch3;branch4), 0, nil, 
true)
check(qgrep(include pattern  '{branch2,branch4}', stderr))
check(qgrep(exclude pattern  '{branch1,branch3}', stderr))


-- 
-- Stephe

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

Re: [Monotone-devel] Stephe...

[Stephen Leake]

Thomas Keller m...@thomaskeller.biz writes:

 ...just looking around the corner to tell you that you're doing a great
 job for monotone! Thank you very much for taking care of all these
 bugs!

Thanks.


-- 
-- Stephe

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

Re: [Monotone-devel] Updated Issue 148 - 'mtn list unknown' omits items in an unknown directory (monotone)

[Stephen Leake]

Any objections to merging nvm.issue-148-80 to main?

-- 
-- Stephe

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

Re: [Monotone-devel] Updated Issue 201 - pull and db check have different opinion on whether branch certs are needed (monotone)

[Stephen Leake]

Markus Wanner mar...@bluegap.ch writes:

 Stephen,

 On 06/25/2012 12:55 PM, c...@monotone.ca wrote:
 # By Stephen Leake, Jun 25, 2012:
 
 consensus on relaxing db check, so that's done in 
 a4549e0dd9f2288465eb61bb885ceaaf07359776

 Thanks, perfect.

 (I couldn't review the change, as it's not on code.monotone.ca, yet.
 However, I'm glad you informed, as that I was about to do the same.)

Sorry, forgot to sync. Done now.

-- 
-- Stephe

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

[Monotone-devel] issue 68

[Stephen Leake]

I'm going thru all the mtn issues, looking for things to fix.

issue 68 reports an invariant failure in mtn 0.36, but it doesn't give
enough info to reproduce the problem. I suggest we mark this issue
'WontFix', so we don't have to think about it any more.

-- 
-- Stephe

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

Re: [Monotone-devel] issue 201; missing certs are easily generated, but reported as a serious problem

[Stephen Leake]

Stephen Leake stephen_le...@stephe-leake.org writes:

 One fix is very simple; in database_check.cc, take missing_certs out of
 the 'serious' sum. Then 'db check' reports:

 mtn: revision 114f6aa58c7707bf83516d4080ca6268c36640ad missing branch cert
 mtn: warning: 1 missing certs
 mtn: check complete: 2 files; 2 rosters; 2 revisions; 1 keys; 7 certs; 3 
 heights; 1 branches
 mtn: total problems detected: 1 (0 serious)
 mtn: minor problems detected


 On the other hand, perhaps some certs are more important than others? We
 could count branch certs separately from author and date, and then just
 leave missing_branch_certs out of the 'serious' sum.

Another fix, as the problem report suggests, is to change the netsync
code to pull all certs for a revision; only use the branch filter to
decide which revision to pull.

-- 
-- Stephe

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

[Monotone-devel] status of issue 203?

[Stephen Leake]

I'm trying to understand issue 203.

I have a Debian system, with testing installed as the main system, and
unstable in a chroot.

I don't see any package named 'eglibc', nor 'glibc'. There is
'libglib2.0-0', which is at version 2.32.3-1 in both testing and
unstable (just refreshed everything today).

Monotone nvm head compiles clean on this system.

So can we declare this issue fixed, or am I missing something?

-- 
-- Stephe

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