Re: [Monotone-devel] C++11

[Thomas Keller]

Hi Markus!

Markus Wanner schrieb:
 Obviously, the former offers little benefit: We could possibly add minor
 #ifdef'd optimizations. For example using perfect forwarding and move
 constructors to avoid some copying if C++11 is used.
 
 The latter seems much more interesting, but is a much heftier change as
 well. Before I proceed with that branch, I'd like to get some feedback
 and opinions.

Since I'm not developing with C++ anymore on a daily basis, would you
mind to give guys like me some examples / judgement why monotone should
switch to C++11? I could think of having less code in monotone because
more is taken care of already in the stdlib, but some examples would be
nice.

Thanks!
Thomas.

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



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

Re: [Monotone-devel] monotone 1.1 released

[Thomas Keller]

Stephen Leake schrieb:
 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.

Send me a new one via PM, I can set it up.

Thomas.

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



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

Re: [Monotone-devel] monotone 1.1 released

[Thomas Keller]

Markus Wanner schrieb:
 Great!
 
 Shall we remove the Mac OS X Installer and Binary options from the
 website's downloads site and recommend MacPorts? Or how do I build these
 universal binaries?

Building these universal binaries is a PITA (I think its still described
in mac/readme-mac.txt, but horrible outdated), since we depend on many
external libraries that need to be build and statically linked to us
beforehand. Its better to point users at MacPorts and later also to
Homebrew, once the latter has picked up 1.1 as well [0].

Thomas.


[0]
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/monotone.rb

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



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

Re: [Monotone-devel] monotone 1.1 released

[Thomas Keller]

Markus Wanner schrieb:
 the monotone team just released version 1.1 of its versions control
 system. This is mainly a maintenance release, focusing on stability and
 compatibility. It also fixes various bugs that have accumulated over the
 years.

Hi Markus!

Thanks for the effort!


 The sources are available from the usual location [0], static builds,
 packages and installers should be available, shortly.
 
 Here's the relevant portion from the NEWS file:
 
 ...
 - 'automate atttributes' now also works without a workspace
   and returns the attributes for a specific file from the
   revision's manifest

Oops, that was me that entered this passage three years ago, of course
there is no automate atttributes, but only a automate get_attributes
command. I fixed and pushed this to nvm.

Also, I updated http://wiki.monotone.ca/AutomateVersions/ to reflect the
minor interface bump and documented the added / changed commands.

Lastly, I pushed an update to MacPorts, so monotone 1.1 should be
available via their ports tree soon-ish as well.

Thomas.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Markus Wanner schrieb:
 Thomas,
 
 thanks for testing!
 
 On 05/03/2014 01:39 AM, Thomas Keller wrote:
 I'm on 10.9 (Mavericks) here. I had no recent enough mtn installation
 around, so I had to copy sources and build from there.

 Things that I've stumbled upon  so far:

 * Don't use gcc from MacPorts to build, it will bring up weird linker
   errors (see my previous post from February), but stick to plain clang
   (which Apple advertises as gcc and g++ in the /usr/bin prefix)
 
 Just out of curiosity: What clang version is it?

Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

 * If gettext is not available, make (not make dist) fails with a
   cryptic

   make[2]: Circular po/sv.gmo - po/sv.gmo dependency dropped.

   I guess this is because of Makefile.am's

   po/%.gmo: $(srcdir)/po/%.gmo
 cp $ $@

   which looks a bit fishy indeed.
 
 Hm.. that's a good hint! I'll check.
 
 `make -j$N` for any N bigger than 1 usually fails hanging at some txt2c
 step, here. Up to date, I couldn't figure why and started to suspect a
 bug in make. Maybe that's related. I see a small chance that's related...

I think this here is really just about a wrong rule in Makefile.am. It
survived for so long because most people already install needed
dependencies before letting out build system stumble upon it.

 * make install failed for me, because mtn.1 seems to be deleted right
   after it was created, so it cannot be installed. So `make mtn.1` does
   create and delete the file, but when I execute the commands of that
   target in my own shell, mtn.1 persists. Weird, but a minor.
 
 Weird, indeed. Adding to my todo list: Makefile massage

Ok, thanks!
Thomas.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Markus Wanner schrieb:
 On 05/03/2014 02:08 AM, Thomas Keller wrote:
 test/unit/tests/../../../src/dates.cc:493: detected user error,
 'E(tb.tm_sec == check.tm_sec  tb.tm_min == check.tm_min  tb.tm_hour
 == check.tm_hour  tb.tm_mday == check.tm_mday  tb.tm_mon ==
 check.tm_mon  tb.tm_year == check.tm_year  tb.tm_wday ==
 check.tm_wday  tb.tm_yday == check.tm_yday  tb.tm_isdst ==
 check.tm_isdst)' violated
 UNCAUGHT EXCEPTION: recoverable_failure: misuse: date 'Fri Dec 13
 20:45:51 1901' is out of range and cannot be parsed
 Test dates:roundtrip_localtimes failed.
 
 Ouch. Let's fix that before the release...
 
 Anything special WRT timezone on that box, that you can think of? Or
 with Mac OS X or MacPorts in general?

Not to my knowledge. I looked into the sources and saw that this
assertion is triggered when mktime returns -1, i.e. could not interprete
the single date components as a valid UNIX timestamp. I have to read the
platform's mktime(1) more closely to find out what the issue is here.

 The functional test suite ran through, expect one test as well,
 ssh_agent. Here the ssh-agent is locally found and started, but monotone
 doesn't seem to be able to connect to it:

 mtn: warning: ssh_agent: failed to connect to agent: No such file or
 directory
 mtn: misuse: no ssh-agent is available, cannot add key
 46ec58576f9e4f34a9eede521422aa5fd299dc50
 
 Maybe also an issue with spaces in the directory? I'm running a test, now.

I don't know how the ssh-agent works in detail, but I thought that it
communicates over a local pip / socket of some sort that is referenced
by the SSH_AUTH_SOCK environment variable - and that pointed to a path
without spaces
(/var/folders/mb/xkzjkh3d5_g0bv46qhzlznv8gn/T//ssh-wVNuN9lwzL5e/agent.45988).

 And finally, the extra tests ran despite the mtn-cleanup test. This is
 because of a path-quoting issue that I will fix in a few. I'll try to
 have a closer look at the other two issues tomorrow.
 
 Thanks, much appreciated. I should be mostly around for today and still
 hope to bundle a release tarball soon-ish.

I have family time now, will look into it this evening.

Thomas.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Markus Wanner schrieb:
 On 05/03/2014 01:39 AM, Thomas Keller wrote:
   make[2]: Circular po/sv.gmo - po/sv.gmo dependency dropped.

   I guess this is because of Makefile.am's

   po/%.gmo: $(srcdir)/po/%.gmo
 cp $ $@

   which looks a bit fishy indeed.
 
 This starts to look a lot less fishy once you take VPATH builds into
 account. Without it `make all` fails if $(srcdir) != $(builddir) with:
 
   *** No rule to make target `po/sv.gmo', needed by `all-nls'.  Stop.
 
 And if $(srcdir) == $(builddir), dropping the dependency is just the
 right thing to do.

Well, I haven't told you all of the story. This is the rest of the
output in case srcdir == builddir, it fails the build!

make[2]: Circular po/sv.gmo - po/sv.gmo dependency dropped.
cp  po/sv.gmo
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
   cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ...
target_directory
make[2]: *** [po/sv.gmo] Error 64
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Thomas.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Markus Wanner schrieb:
 Thomas,
 
 (or anybody on Mac OS X)
 
 On 05/03/2014 08:40 PM, Markus Wanner wrote:
 I'll try to see what I can do with such a crippled mktime().
 
 Can you please try the attached simple test program?
 
   $ g++ -o test test.cc
   $ ./test

I'm running a 64 bit OS X and your test program reports mktime seems okay.

Thomas.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Markus Wanner schrieb:
 On 05/03/2014 11:46 PM, Thomas Keller wrote:
 I'm running a 64 bit OS X and your test program reports mktime seems okay.
 
 Thanks. Surprises me. Although: I had a time zone issue in that test
 program itself, though.
 
 I could finally arrange for an Mac OS X box (Mountain Lion) that
 thankfully reproduced the issue. I'm just about to commit a fix.
 Attached a corrected variant of the test code. On my Mac OS X box it
 yields: Lower boundary wrong (got -1)

Yep, I get this as well. Just after I've sent my previous mail I looked
at the unit-test's code again and spotted this:

  // this is the valid range of dates supported by 32 bit time_t
  date_t start(1901-12-13T20:45:52);
  date_t end(2038-01-19T03:14:07);

So I guess the timestamp that it supposed to handle
(1901-12-13T20:45:51) should not be acceptable with a 32 bit time_t
and it should fail in such a case. But yeah, I'm just scratching on the
surface, you're way more fluent and faster than me in this area :)

Thomas.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Hi Markus!

Markus Wanner schrieb:
 Hi,
 
 we're mostly ready for a 1.1 release. I fixed the intermittent issues in
 the extra tests. The revived build farm looks reasonably green, now.

Thanks for the effort!

 What's clearly missing is MacOS X. So if you have access to a box with
 that OS, please give it a spin (and consider providing a buildbot slave,
 please).

I'm on 10.9 (Mavericks) here. I had no recent enough mtn installation
around, so I had to copy sources and build from there.

Things that I've stumbled upon  so far:

* Don't use gcc from MacPorts to build, it will bring up weird linker
  errors (see my previous post from February), but stick to plain clang
  (which Apple advertises as gcc and g++ in the /usr/bin prefix)

* Mix-in libidn, liblua, libbotan, libpcre and else from MacPorts via
  CXXFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib (where
  /opt/local is the MacPorts prefix)

* Monotone has no support for botan's special versioned package-
  config file that botan seems to use since 1.10, so some more flag
  magic was needed, namely
  botan_CFLAGS=-I/opt/local/include/botan-1.10
  botan_LIBS=-lbotan-1.10

* If gettext is not available, make (not make dist) fails with a
  cryptic

  make[2]: Circular po/sv.gmo - po/sv.gmo dependency dropped.

  I guess this is because of Makefile.am's

  po/%.gmo: $(srcdir)/po/%.gmo
cp $ $@

  which looks a bit fishy indeed.

  When gettext is installed, this does not pop up, of course.

* make install failed for me, because mtn.1 seems to be deleted right
  after it was created, so it cannot be installed. So `make mtn.1` does
  create and delete the file, but when I execute the commands of that
  target in my own shell, mtn.1 persists. Weird, but a minor.

I'm currently executing make check and will report the results of that
tomorrow.

Thomas.

PS: German translation has been updated.

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



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

Re: [Monotone-devel] status of release 1.1

[Thomas Keller]

Thomas Keller schrieb:
 I'm currently executing make check and will report the results of that
 tomorrow.

Faster than I thought, unit-tests ran through, with one error in
dates_roundtrip_localtimes, relevant tester.log output follows:


parsing date 'Fri Dec 13 20:45:51 1901' with format '%c'
localtime 1901/12/13 20:45:51 WD 5 YD 0 DST -1
-1 seconds UTC since unix epoch
Encountered an error while musing upon the following:
saving current work set: 3 items
finished saving work set
contents of work set:
Current work set: 3 items
- begin 'system_flavour' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:119)
Darwin 13.1.0 Darwin Kernel Version 13.1.0: Wed Apr  2 23:52:02 PDT
2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
-   end 'system_flavour' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:119)
- begin 'cmdline_string' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:133)
'/Users/thomas/Entwicklung/Open
Source/net.venge.monotone/test/bin/unit_tester',
'dates:roundtrip_localtimes'
-   end 'cmdline_string' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:133)
- begin 'string(lc_all)' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:138)
C
-   end 'string(lc_all)' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:138)

test/unit/tests/../../../src/dates.cc:493: detected user error,
'E(tb.tm_sec == check.tm_sec  tb.tm_min == check.tm_min  tb.tm_hour
== check.tm_hour  tb.tm_mday == check.tm_mday  tb.tm_mon ==
check.tm_mon  tb.tm_year == check.tm_year  tb.tm_wday ==
check.tm_wday  tb.tm_yday == check.tm_yday  tb.tm_isdst ==
check.tm_isdst)' violated
UNCAUGHT EXCEPTION: recoverable_failure: misuse: date 'Fri Dec 13
20:45:51 1901' is out of range and cannot be parsed
Test dates:roundtrip_localtimes failed.


This test never failed on me in earlier OS X versions, seems as if
something changed.


The functional test suite ran through, expect one test as well,
ssh_agent. Here the ssh-agent is locally found and started, but monotone
doesn't seem to be able to connect to it:

mtn: warning: ssh_agent: failed to connect to agent: No such file or
directory
mtn: misuse: no ssh-agent is available, cannot add key
46ec58576f9e4f34a9eede521422aa5fd299dc50


And finally, the extra tests ran despite the mtn-cleanup test. This is
because of a path-quoting issue that I will fix in a few. I'll try to
have a closer look at the other two issues tomorrow.

Have a good night.
Thomas.


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



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

Re: [Monotone-devel] I... well, I quit ;-)

[Thomas Keller]

Richard Levitte schrieb:
 Hey guys,
 
 you may have noticed that I haven't said much of a peep for quite a
 while.  Fact is, I've generally been pulling away from programming
 as a passion since a few years back.  I may still do some to be able
 to pay the bills, but that's about all.  Life changes, life turns,
 that sort of thing...  For those who want to know, I've restarted
 another passion of mine, photography and art based on that.
 
 I may stick around as a translator for a while more, in the hope that
 someone else turns up to take over that part.  How is it these days,
 is there a translators mailing list or is this the one?
 
 I just thought that it was time to make this official instead of just
 lurking.

Hey Richard!

Thanks for all the work and support from you over the years! Surely,
life moves on and I wish you all the best for you and your upcoming
adventures (I heard one usually has to go outside to make good photos).

Maybe we'll meet again some time in Stockholm, when I'm nearby on
vacation :)

Again, all the best for you,
Thomas.

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



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

Re: [Monotone-devel] oversized payload

[Thomas Keller]

Hi Hugo!


But what is the policy of monotone wrt file size that can be checked
into a repository?


The maximum compressed packet size is 256MB (see src/constants.hh, 
netcmd_payload_limit is 2  27).


I cannot tell whether this was set to this value on purpose or by 
accident, but surely 256MB do not sound a lot roughly ten years after 
this code was probably written :)


Thomas.

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

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

Re: [Monotone-devel] 1.1 release!

[Thomas Keller]

Hi Markus! 

Thanks for stepping up! The website might not be in sync as there often were 
script problems in the past. I'd just ssh on the box, fetch the latest content 
and commit it. 

If you need any help there, drop me a private message. 

Thomas. 



Markus Wanner mar...@bluegap.ch schrieb:
On 09/20/2013 09:58 PM, Markus Wanner wrote:
 On 09/11/2013 07:13 PM, Jeff Rizzo wrote:
 Any chance of getting a new release this year?  At the very least,
 pkgsrc (pkgsrc.org) is having trouble because of building with Lua
5.2,
 and it would be nice to have an actual release to deal with it.
 
 I'd also appreciate a 1.1 release. The debian package accumulated
quite
 a lot of patches since 1.0...
 
 I'm not sure about the current status of lua 5.2, though.
 
 I vaguely remember some kind of todo list for releases... can
somebody
 provide me a link?

thm_ pointed me to the notes/release-checklist.txt in the sources of
monotone itself. Thanks.

I'm happy to coordinate a release.

Richard, what's the status of the buildbot. It doesn't trigger any
builds, ATM. Do you need help?

Thomas, the website doesn't match
net.venge.monotone.website{,.mainsite}. Am I looking at the wrong
branches? Or is it just not up to date?

Regards

Markus Wanner

-- 
Sent from my Android 

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

[Monotone-devel] Christmas Release

[Thomas Keller]

Hi all!

The question regarding a new monotone release arose recently... wouldn't
it be great to release it as christmas present for the last loyal
users we have...?

Thomas.

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



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

[Monotone-devel] Stephe...

[Thomas Keller]

...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!

Thomas.

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











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

[Monotone-devel] New indefero version deployed

[Thomas Keller]

Hi all!

I've deployed a new version of Indefero (1.3.2) and merged it with our
custom layout. Let me know if you find any hiccups (note though that you
should clear your browser cache before... :)

A list of notable changes since v1.2 (which is what we were previously
running) can be found here:

  http://projects.ceondo.com/p/indefero/page/News/

(The activity calculation is not enabled for our setup, btw...)

Thomas.

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



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

Re: [Monotone-devel] monotone and buildbot upgraded on code.monotone.ca

[Thomas Keller]

Am 25.04.12 15:31, schrieb Richard Levitte:
 We're now running v1.0 (we were running some pre-1.0 before, I've no
 idea why we hadn't upgraded it before).
 All databases I know about have been migrated accordingly.

You forgot the wiki database and that throwed a myriad of errors into
the zoho mail account, because our cron checks for updates there every
10 minutes... I fixed that for you :)

 Also, I've upgraded buildbot to v1.8.6p1.  It already has support for
 monotone build in (thanks to yours truly ;-)).  I suggest buildslaves
 get upgraded to 1.8.3 or higher.

Very cool, thanks for your work!

Thomas.

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



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

Re: [Monotone-devel] Status of blue sky ideas?

[Thomas Keller]

Am 13.12.11 00:33, schrieb Judson Lester:
 [...] So, seeing an email from a few months back that seemed to suggest that
 monotone is kind of done - no one seems to be keen to continue
 development, and everyone seems satisfied - was a little disheartening.
 
 What is the status of monotone as a project?

Software - and especially Open Source software - is only insofar
complete as long as no one complains about something and eventually
hacks on it.

The thing with monotone now is probably that there are just too few
people using and therefor possibly complaining (enough) about stuff. And
even if they'd complain, the alternatives seem - most of the time - much
more attractive.

monotone's code base ages in the meantime, and while it is still very,
very sophisticated in many areas, it might just scare away younger devs
because its C++, and not Ruby, or Python, or Java.

So yes, development kind of ceased, and I'm not happy on that fact
either, but its actually all about participation. It brings us nothing
to whine about the fact that nobody hacks on it; if you, or me or
anybody else _cares_ about monotone and starts hacking on it again, than
it will live further, if not, it will die. Its as simple as that.

Unfortunately my personal time for open source projects is very, very
limited these days, so I cannot bring much into this anymore. We really
need fresh blood...

Thomas.

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



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

[Monotone-devel] openSUSE rpms (or lack thereof)

[Thomas Keller]

Hi all!

I dropped my old openSUSE work setup a couple of weeks ago and therefor
have no way to build (or even test) openSUSE rpms anymore. It would be
cool if somebody could pick up the maintenance of these packages,
otherwise they'll probably fall behind between the regular releases and
even vanish some day completely.

I must admit that I was never a profession RPM packager, so for somebody
who's more proficient with rpm packaging the spec file might look like
garbage, but then again, one could improve many things there, like for
example offer an additional, separate server package, and things like
this. And even for starters the OBS - the opensuse build system - is
very easy to use and to play around with, everything can theoretically
be done through the web interface (whilst this is not recommended,
though :)).

So yeah, if you, or you, or even you are up for the task, I'd be quite
happy!

Thanks for reading,
Thomas.

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



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

Re: [Monotone-devel] [Monotone-users] Some repositories broken (SQL logic error)

[Thomas Keller]

Am 17.11.11 19:12, schrieb Dirk Heinrichs:
 Hi,
 
 some of my repositories seem to be broken. A checkout attempt and mtn
 db check both give the following error:
 
 mtn: error: sqlite error: SQL logic error or missing database
 
 I also tried to dump one of the databases, which gives this:
 
 % mtn db dump --db=~/monotone/vcontrol.mtn 21|head
 mtn: fatal: std::terminate() - exception thrown while handling another
 exception
 mtn: This is almost certainly a bug in monotone.
 mtn: Please report this error message, the output of 'mtn version --full',
 mtn: and a description of what you were doing to
 'https://code.monotone.ca/p/monotone/issues/'.
 mtn: wrote debugging log to /afs/altum.de/home/heini/.monotone/dump
 mtn: if reporting a bug, please include this file
 
 Here's the content of the dump file:
 
 % cat /afs/altum.de/home/heini/.monotone/dump
 Encountered an error while musing upon the following:
 src/database.cc:804: detected internal error, 'I(stepresult ==
 SQLITE_DONE || stepresult == SQLITE_ROW)' violated
 Encountered an error while musing upon the following:
 src/migrate_schema.cc:105: detected system error, 'E(false)' violated
 Current work set: 4 items
 - begin 'system_flavour' (in virtual void sanity::initialize(int,
 char**, const char*), at src/sanity.cc:119)
 Linux 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64
 -   end 'system_flavour' (in virtual void sanity::initialize(int,
 char**, const char*), at src/sanity.cc:119)
 - begin 'cmdline_string' (in virtual void sanity::initialize(int,
 char**, const char*), at src/sanity.cc:133)
 'mtn', 'db', 'dump', '--db=~/monotone/vcontrol.mtn'
 -   end 'cmdline_string' (in virtual void sanity::initialize(int,
 char**, const char*), at src/sanity.cc:133)
 - begin 'string(lc_all)' (in virtual void sanity::initialize(int,
 char**, const char*), at src/sanity.cc:138)
 C
 -   end 'string(lc_all)' (in virtual void sanity::initialize(int,
 char**, const char*), at src/sanity.cc:138)
 - begin 'full_version_string' (in virtual void
 mtn_sanity::initialize(int, char**, const char*), at src/mtn-sanity.cc:32)
 monotone 1.0 (base revision: a7c3a1d9de1ba7a62c9dd9efee17252234bb502c)
 Running on  : Linux 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2
 13:27:26 UTC 2011 x86_64
 C++ compiler: GNU C++ version 4.6.1
 C++ standard library: GNU libstdc++ version 20110903
 Boost version   : 1_46_1
 SQLite version  : 3.7.7 (compiled against 3.7.7)
 Lua version : Lua 5.1
 PCRE version: 8.12 2011-01-15 (compiled against 8.12)
 Botan version   : 1.8.13 (compiled against 1.8.13)
 Changes since base revision:
 format_version 1
 
 new_manifest [b252820fde344fd3f5d023fd91de86522baa671d]
 
 old_revision [a7c3a1d9de1ba7a62c9dd9efee17252234bb502c]
 
   Generated from data cached in the distribution;
   further changes may have been made.
 -   end 'full_version_string' (in virtual void
 mtn_sanity::initialize(int, char**, const char*), at src/mtn-sanity.cc:32)
 
 Anything I can do to repair my repositories?

Hi Dirk!

We'd be interested getting our hands at this database. From what I can
see in the code sqlite3_step probably returns an unexpected state such
as SQLITE_ERROR which could hint at a constraint violation or something
else weird.

Anyways, without having the database to test and debug into it will be
rather hard to figure out the real problem. Can you make it available
somewhere? If privacy is an option, you could also just send it to me.

Thomas.

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



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

Re: [Monotone-devel] Time to wake up?

[Thomas Keller]

Am 02.11.11 08:47, schrieb Richard Levitte:
 It's been pretty silent since this summer, and I'm wondering, where do
 we stand?  I've seen Richard Hopkins do some work on regex cache and a
 few other things, and there are a number of other branches that need
 being looked at as well.
 
 So, what I mostly wonder right now is, who's in?  Apart from Richard,
 that is ;-)

I'm more or less out for the next months, I'm way too busy with customer
projects to do substantial OS development. Very sorry about that.

Thomas.

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



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

Re: [Monotone-devel] monotone.ca over IPv6

[Thomas Keller]

Am 08.10.11 18:52, schrieb Lapo Luchini:
 http://colabti.org/irclogger/irclogger_log/monotone?date=2011-10-05#l2
 
 The server is now correctly working over IPv6 again.
 Feel free to contact me if problems should arise.

Many thanks!

Thomas.

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



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

Re: [Monotone-devel] New branch name with no other changes

[Thomas Keller]

Am 10.06.2011 16:26, schrieb Hendrik Boom:
 Actually, the approve command worked fine, though it took a few moments 
 to determine the right revision ID.  Maybe approving the revision in the 
 current workspace should be an option on that command?  I wouldn't want 
 it to be the default: too easy to approve the wrong thing by accident.

You could use

mtn approve -b new.branch w:

for the very same purpose and don't have to figure out the current rev
id at all.

Thomas.

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




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

Re: [Monotone-devel] Improving documentation (was Re: New branch name with no other changes)

[Thomas Keller]

Am 10.06.11 18:59, schrieb Aaron W. Hsu:
 On Fri, 10 Jun 2011 12:45:34 -0400, Hendrik Boom
 hend...@topoi.pooq.com wrote:
 
 Presumably w: is a form of revision-id, which I'm sure is documented
 somewhere else where I didn't happen to look.
 
 I frequently search for the revision pattern documentation and I always
 struggle.

An overview of the available revision selectors and other key
information could be part of a cheat sheet for monotone which we
wanted to have long ago. Any nicely layouted, contributed work in this
area would be greatly appreciated and it would also be publically and
prominently linked :)~

*hint, hint*

Thomas.

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



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

[Monotone-devel] Fwd: CafePress Online Agreements update notice

[Thomas Keller]

Hi all!

Cafepress is going to change their Terms of Service or Content Owner
Agreement as they call it. Several things are quite bad with the new
agreement (content licensing, product removal after 12 months of
inactivity, raised processing fees) so that I'm going to close our
shop (http://www.cafepress.de/monotone_rcs) there in the next couple of
days.

So if you thought about purchasing anything from there, this is your
last chance to place your order.

Thomas.


 Original-Nachricht 
Betreff: CafePress Online Agreements update notice
Datum: Wed, 08 Jun 2011 17:07:46 -0600
Von: CafePress contentow...@cafepress.com
Antwort an: CafePress.com
reply-fe9a15767065017c77-3051_html-270895934-1002810-8...@news.cafepress.com
An: m...@thomaskeller.biz

Online Agreements Update

Dear CafePress Member,

Thanks for helping make CafePress the world's destination for customized
products. We are updating your Online Agreements. These Online
Agreements will be revised effected June 23, 2011, and the material
changes include:

- Updates to the Content Owner Agreement (formerly Seller Agreement):--
Section 3.2: Content

CafePress will retain the right to remove content from the CafePress
system after 12 months of inactivity.-- Section 4.2: Licensing Your
Content to CafePress
(v): CafePress reserves the right to sell Products and/or Content from
the CafePress Marketplace at its sole discretion for 3rd party feeds and
set pricing.
(vi): CafePress reserves the right to sell Products and/or Content
available through the CafePress Marketplace to other retailers or
wholesalers at prices determined by CafePress.-- Section 7.4: Processing
Fees
The processing fee (inactivity fee) is being increased from $5 to $10.
If CafePress owes you accrued compensation that is less than the Payment
Threshold for at least 365 days, then CafePress may send you payment of
such accrued compensation minus a $10 processing fee.-- Section 7.6:
Termination Fees
The termination fee is being increased from $5 to $10. If you or
CafePress terminate your Account, and you have less than $25 in accrued
but unpaid royalties then outstanding, CafePress may charge you a $10
processing fee when sending you your final payment to cover its
administrative costs.
- Updates to the Marketplace and Shop Services (formerly Seller
Services):-- Bulk Discount
The pricing and tiers for the Bulk Discount program have been updated.
- Updates to the language throughout all agreements including
definitions and actions on Prohibited Content and Indemnification
responsibilities.
[...]




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

Re: [Monotone-devel] New branch name with no other changes

[Thomas Keller]

Am 09.06.11 20:14, schrieb Hendrik Boom:
 I checked out a new workspace, and I want to check it in again unchenged 
 with a new branch name  -- the one I want to use to make changes.  I'd 
 like to make it clear that the new branch is starting in the same state 
 as the current head in the old one.
 
 But when I try to check in, it fails:
 
 hendrik@notlookedfor:~/fanfic/theShadowChronicles-MarkMacKinnon/edited$ 
 mtn commit 
 --branch=com.pooq.hendrik.othersfanfic.theShadowChronicles.cleanup
 mtn: misuse: no changes to commit
 
 Well, yes, there were no changes in any of the files, but the branch was 
 different.
 
 Is there some conceptual reason why a branch name change should not be 
 enough to do a commit?

Yes, because the branch name is not part of the revision nor the
manifest. Its just metadata tacked onto an already created revision. In
your case it should be enough to issue a new branch cert either through
mtn cert or mtn approve.

Thomas.

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



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

Re: [Monotone-devel] Using the mouse logo on a book cover

[Thomas Keller]

Hi Mathias!

 last month I announced an introductory text on monotone in German
 language at the monotone-user list:
 http://lists.nongnu.org/archive/html/monotone-users/2011-05/msg0.html
 
 This text is grown into more than 50 pages and I want to put a book on
 demand version on Lulu (http://www.lulu.com/). For the cover page I
 would like to use the mouse logo from the monotone homepage. Therefore
 I'd like to ask whether there are objections against using it on the
 book cover and, if not, to what I should adhere when I use it.

As I already told you privately before, the license of the mouse should
be GPLv2+, as is the rest of monotone's sources. (The documentation was
once relicensed to GPLv2+ IIRC, so the logo was most likely part of it.)
Since I'm the author of the modified / gradiented version I can only
say I grant you the needed rights using it as cover for your book.

If anybody has a different opinion, he should speak up now or forever
hold his peace :)

 I would also need a bigger version of the image for the cover.
 From where could I get this?

Its source is scalable SVG and can be obtained here:

https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/doc/figures/monotone-logo.svg

 Anyway, thanks for your work on monotone.

Thank you for using it and improving its perception!

Thomas.

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



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

[Monotone-devel] GPLv3 code in monotone

[Thomas Keller]

Hi!

This is a follow-up on
https://bugzilla.novell.com/show_bug.cgi?id=684822, where I was asked
to clarify the license of the openSUSE monotone package.

Currently, this is stating GPLv2+, but the reporter needs some
clarification because we have some GPLv3+ code in the package
(src/{unix,win32}/parse_date.cc). From the original ticket:

---

oS:

| // Copyright (C) $YEAR $OWNERL
| //
| // This program is made available under the GNU GPL version 3.0 or
| // greater. See the accompanying file COPYING for details.
| //
| // This program is distributed WITHOUT ANY WARRANTY; without even the
| // implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
| // PURPOSE.

The file itself is quite short and it looks as if the header may have
been added automatically, but this should be confirmed upstream.

---

me:

The copyright has been clarified with a proper year and owner note in
the most recent version (1.0, released on March 26th). I
submit-requested this new version already, but didn't got an answer so
far (#65356).

The question for me now (from a legal point of view) is whether it is a
problem for you (or anybody else) if a project that is tagged as GPLv2+
has single GPLv3+-licensed files in it?

---

oS:

 The question for me now (from a legal point of view) is whether it is
 a problem for you (or anybody else) if a project that is tagged as
 GPLv2+ has single GPLv3+-licensed files in it?

It is not a problem but it could mean that the entire resulting derived
work would be GPLv3+ rather than GPLv2+. If this is the case, the spec
file should state that the license is GPLv3+.

Therefore, it seems that we need to decide on whether or not the file is:

(a) used at all
(b) used in a copyright relevant way with GPLv2+ code (i.e. is a derived
work created)
(c) correctly licensed under GPLv3+ (i.e. perhaps it was a mistake by
upstream)

If (a) and (b) can be answered in the negative we don't (strictly
speaking) have to answer (c) - though it would be desirable generally.

---


I then answered that the files are used (a) and that it was not an
accident (c), but I'm unsure about the derived work clause. I'm seeing
the following solutions (ordered by impact):

1) document in README or somewhere else that parts of the code use
GPLv3+ and give packagers a hint what license they should use when they
package monotone
2) relicense the mentioned files as GPLv2+
3) relicense everything of mtn GPLv3+

Opinions anyone?
Thomas.

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



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

Re: [Monotone-devel] GPLv3 code in monotone

[Thomas Keller]

Am 19.05.11 16:59, schrieb Zack Weinberg:

Nice to read you! :)

 I think that migration to GPLv3 remains premature at this time, and we
 should relicense the v3 files down to v2.

+1 from me as well.

We probably need to create a patch release with this change, so
downstream's license issues are actually reflected properly, right?

I don't want to temporarily make the package GPLv3 and wait for the
next release to downgrade it again to GPLv2... do we actually have
anything for a 1.0.1 release beside this? I came across a few Win32
issues lately, but I have no time to look after them.

Thomas.

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



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

[Monotone-devel] Fwd: Monotone and ViewMTN

[Thomas Keller]

Could somebody please have a look at Konstantin's problem? I'm
unfortunately quite busy currently.

Thanks,
Thomas.

 Original-Nachricht 
Betreff: Monotone and ViewMTN
Datum: Mon, 16 May 2011 19:41:33 -0700 (PDT)
Von: Konstantin Minevsky k.minev...@yahoo.com
Antwort an: Konstantin Minevsky k.minev...@yahoo.com
An: m...@thomaskeller.biz m...@thomaskeller.biz

Greetings, Thomas!

I was looking for help all over the Internet, but with no success. I
hope you can shed some light on my problem.
I've got Monotone (0.48) installed along with ViewMTN on Debian Squeeze
box. Everything was working fine before update from Lenny to Squeeze. 
But now our ViewMTN page shows nothing: http://mt.xaraya.com/ 
Logs show nothing, except Apache2:
FastCGI: server /var/www/xaraya/mt.xaraya.com/viewmtn.py stderr:
'exception writing to child process; attempting restart: Traceback (most
recent call last):\\n  File /var/www/xaraya/mt.xaraya.com/mtn.py, line
168, in __run\\nself.process.tochild.flush()\\nIOError: [Errno 32]
Broken pipe\\n'

Could this be a reason for a blank page?
 
Best regards,
Konstantin



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

Re: [Monotone-devel] permissions and identity

[Thomas Keller]

Am 16.05.11 23:35, schrieb Hendrik Boom:
 I'm using usher with monotone.
 Do I have it right?
 
 User identities (the public keys) are kept in the monotone databases.  
 Presumably every database can have different sets of user identities.  
 
 But private keys are kept in a .monotone/keys directory, which is the 
 same for all databases.
 
 So the databases can differ as to public keys, but have to agree on 
 provate keys.
 
 Finally, the set of branches users can read and write to is kept in 
 files different directry, .monotone/read-permissions and 
 .monotone/write-permissions.  This even though moltiple data bases 
 probably provide completely different branches.
 
 
 Is there a rationale for this division of responsibilities, or did it 
 just appear more or less by accident?

I'd say its by accident. If you configure usher with local servers,
i.e. independently running mtn instances, you should give each instance
its own configuration directory with --confdir.

The monotone server entry for our own usher instance for example looks
like this:

server monotone
 local --confdir /path/to/monotone -d
/path/to/monotone/database.mtn --ticker=dot --timestamps

And underknees /path/to/monotone the full configuration tree with
private keys, read- / write-permission files, monotonerc and so on is
expanded.

Thomas.

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



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

[Monotone-devel] Parallel test execution (Was: Re: [Monotone-debian] Bug#623734: monotone: FTBFS: test suite timeout)

[Thomas Keller]

Am 27.04.2011 10:19, schrieb Stephen Leake:
 Since it only happens with -jn, this is pretty clearly a bug in make.
 While we could try to find a work-around, I don't see the point.

Lets have a look at our own sources at first. The job server code is in
test/src/unix/tester-plaf.cc, Tim probably has the best expertise in
this area since Zack, who originally wrote most of the code, vanished.

 Just disable parallel builds in the Debian package, and in any other
 official distribution where it is an issue.

This is an intermediate solution, yes. But given the fact that our test
suite literally runs ages and grows from release to release, we should
really tackle down this problem.

Thomas.

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




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

[Monotone-devel] monotone / indefero: information disclosure

[Thomas Keller]

Hi all!

Indefero's monotone plugin might disclose private key information when
Indefero's debug output is switched on.

Since monotone's frontend needs its own private key to authenticate
against a running server, this key is created on-the-fly when a new
project is created, added to the monotone instance and saved in the
project configuration for later usage.

Now when _any_ kind of exception triggers Pluf's error handler, the
current IDF_Project instance is dumped together with the said private
key data that are read from IDF's database.

Therefor please consider to disable Pluf's debug output when you run an
IDF instance with monotone support in production until I found a better
way to handle the frontend authentication issue. You can do this by setting

   $cfg['debug'] = false;

in your src/IDF/conf/idf.php.

Many thanks go to Frère Sébastien Marie sema...@latrappe.fr who
pointed me at this issue.

Thomas.

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




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

Re: [Monotone-devel] [ANNOUNCE] monotone 1.0 released

[Thomas Keller]

Many, many, many thanks for your outstanding work!

A little intro page is now online on monotone.ca :)

Thomas.

Am 26.03.11 11:30, schrieb Richard Levitte:
 Monotone 1.0 is out!
 
 We, the monotone developers, are very proud to release version 1.0 of
 our distributed version control system.
 
 This is a major milestone, and a lot of effort has been made to make
 this release a reality.  It contains quite a number of bug fixes,
 changes and new features.  The tarball can be downloaded here [0],
 binaries are posted on the same page as they come in.
 
 Following is the relevant part of the NEWS [1] file:
 
 Sat Mar 26 10:53:47 UTC 2011
 
 1.0 release.
 
 Changes
 
 - The database scheme was changed; please execute 'mtn db migrate'
   on all your local and remote databases.
 
 - In 'mtn conflicts resolve_first interactive', the result
   file name now defaults to _MTN/resolutions/left_path.
   (fixes monotone issue 103)
 
 - The French monotone translation has been updated and is
   now part of the main distribution again. Many thanks to
   Steve Petruzzello dl...@bluewin.ch for the outstanding
   work!
 
 - get_netsync_(read|write)_permitted have been extended to not
   only read the files read-permissions and write-permissions,
   but also the files in the subdirectories read-permissions.d
   and write-permissions.d.
 
 - monotone now also tracks the workspaces of databases which
   do not reside in a managed location.
 
 - automate now resets the locale to POSIX internally.  This
   means that all scripts can expect the same untranslated
   messages from mtn automate, regardless of the locale of the
   calling process.
 
 - The hook 'get_netsync_key' has been split up into two separate
   hooks, one for client usage ('get_netsync_client_key', with
   the same arguments as the original 'get_netsync_key') and one
   for server usage ('get_netsync_server_key', with a single table
   argument containing all the given '--bind' options).  Please
   review your custom hooks accordingly.
 
 - Short options ('-b', '-d', ...) are no longer completed.  This
   fixes an invariant failure originating from wrong option usage.
   (closes monotone issue 141)
 
 New Features
 
 - 'mtn conflicts store' now outputs a count of the conflicts,
   and the name of the conflicts file.
   (fixes monotone issue 108)
 
 - New 'mtn list workspaces' command which outputs all the
   known workspaces for a specific database.
   (closes monotone issue 129)
 
 Bugs fixed
 
 - The internal line merger will actually preserve your line
   endings now, instead of changing everything to \n.
 
 - Improved the help and fixed the argument indexing in
   'conflicts resolve_first' (fixes monotone issue 101)
 
 - A regression from 0.48 prevented monotone from ordering the
   diff output of individual files alphabetically.
   (fixes monotone issue 102)
 
 - 'mtn privkey' did not recognize private keys solely available
   in the key store. This has been fixed.
 
 - Added compatibility with Botan 1.9.9 and newer.
   (fixes monotone issue 104)
 
 - 'mtn pull' and 'mtn sync' would always say that your workspace
   has not been updated.  Now, it only does that when you used
   the '--update' option and there were no updates.
   (fixes monotone issue 106)
 
 - 'mtn automate remote' and 'mtn automate remote_stdio' now use
   a given database given by an alias to read, store and validate
   a remote server's key fingerprint (fixes monotone issue 95)
 
 - monotone gives a proper error message now if a netsync URI
   with the 'mtn' scheme misses the required host part
   (fixes monotone issue 110)
 
 - Whenever a binary file was removed and one would try to get
   a diff using mtn diff, it would report that /dev/null is
   binary.  This has been changed to it reports the actual
   name of the removed file instead.
   (fixes monotone issue 111)
 
 - monotone no longer wrongly falls back on a :memory: database
   when no database option is given. It also prints out an
   informational message for commands like 'setup' and 'clone'
   that fall back on the configured default database, again,
   if no database is specified for these commands.
   (fixes monotone issue 113)
 
 - If 'mtn serve' is called with one or more '--bind' options,
   then the arguments to these options can now be specified
   again as follows:
 
 'ip-or-host'
 to listen to IP or host on the 

Re: [Monotone-devel] Mtn on Windows... and guitone

[Thomas Keller]

Am 22.03.2011 06:55, schrieb Richard Levitte:
 This problem, btw, looks like it hits doubly...  Worst case scenario,
 it looks like the string it's trying to convert from UTF-8 to ASCII
 isn't really UTF-8 to start with, but also, trying to represent it in
 pure ASCII would prove difficult because of the character-that-should-be-ö.
 
 I don't think that should have us stop 1.0 from coming out, but maybe
 we should have a description of the problem in, say, a file called
 BUGS.  I guess the recommendation is to run monotone in an english
 setting.

We have a big wiki entry that talks in great about all the problems and
while it was updated for 0.32 the last time it is still up-to-date
(simply because we haven't done anything in this regard):

  http://wiki.monotone.ca/FileSystemIssues/

I don't really agree with a BUGS file, mainly because every open bug in
the tracker would have to be added there as well, so I'd rather point
the user there (and create a new task for the above issue and link the
wiki page to it).

  Crashs:
https://code.monotone.ca/p/monotone/issues/label/305/open/
  Defects:
https://code.monotone.ca/p/monotone/issues/label/297/open/
  Incorrect behaviours:
https://code.monotone.ca/p/monotone/issues/label/306/open/
  Other (some can probably be re-tagged from there):
https://code.monotone.ca/p/monotone/issues/label/303/open/

Many entries there are long-existing problems like the one above that
deserve equal attention.

Thomas.

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




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

Re: [Monotone-devel] Release Of Monotone Browser 0.72 And Monotone::AutomateStdio 0.12

[Thomas Keller]

Am 13.03.2011 10:28, schrieb CooSoft Support:
I was thinking of switching the external comparison tool over to
 kdiff3 to match with the recommended merge tool for monotone but
 unfortunately that also suffers from the KDE dependency thing (as you
 would expect).

Since one can configure that on build time this shouldn't actually be
a problem. There is no standard way / script that can be called on any
*nix platform and open some preferred diff / merge tool, as the
freedesktop guys have for the simpler use cases like open a file or
creating an email [0].

Good point. It does seem a little bit 'odd' that a Gtk tool has a
 dependency on KDE. So unless anyone has any objections, I'll switch to
 meld. Remember that this setting just specifies the default application
 to use, the user is free to change it under their own preferences to
 what ever they want. So I think this is more an issue for packagers...
 Please let me know if you don't like this decision.

As I said I'm ok with it and Thomas Moschny is probably the same.

Thomas.

[0] http://portland.freedesktop.org/xdg-utils-1.0/

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




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

Re: [Monotone-devel] Deciding on a date?

[Thomas Keller]

Am 21.03.11 23:16, schrieb Richard Levitte:
 In message 4d867bcd.2080...@thomaskeller.biz on Sun, 20 Mar 2011 23:12:29 
 +0100, Thomas Keller m...@thomaskeller.biz said:
 
 me Speaking of the release manager hat - I announced that I'd want to
 me give my one to another monotone fellower some time last year and
 me Thomas Moschny said he would took over the job, but I haven't seen
 me him around a lot lately (which is understandable being a young
 me father :)), so in turn I'd ask you, Richard, would you like to do
 me the release? You put such a lot work into this and I lately
 me slacked off a lot and devoted more time in other stuff, so I'd say
 me its somewhat your release. I'll support you with blogging /
 me announcing and graphics work wherever I can, just drop me note -
 me what do you say?
 
 It will be my pleasure to make the release :-)
 
 However, looking at my calendar, it's possible I'll have to do it
 early on Saturday instead of Sunday.  If that bothers noone, please,
 then, consider the release period to start Saturday morning.  Anything
 that needs to get into monotone 1.0 has to happen before then.

No problem with that. I'm working on a special 1.0 layout for the
website and it looks quite cool already. Will show off something in the
next couple of days. I'll try put it then online shortly after I noticed
your upload and announcement.

 What will happen when I get started is that I'll start a new branch,
 net.venge.monotone.monotone-1.0, starting from whatever head I find at
 the time, and do the release work from there.

Sounds good.

Thomas.

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



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

[Monotone-devel] Indefero code forge with monotone support released

[Thomas Keller]

Hi all!

The Indefero team [0] today released the first stable version of their
project and source management tool that comes with monotone support. We
have pushed the development a bit over the last couple of months because
we were in the need of a tool that eased the collaboration and provided
easy access to issues and code, and we're quite happy with it as you
might have seen already [1].

If you want to try out Indefero with monotone support, grab the zip [2],
follow the generic instructions to set up the base system [3] and
finally read the instructions how to configure the monotone plugin [4].

We'd love to get some feedback from you!

Thanks for reading,
Thomas.

[0] http://projects.ceondo.com/p/indefero
[1] https://code.monotone.ca
[2] http://projects.ceondo.com/p/indefero/downloads/33/
[3] http://projects.ceondo.com/p/indefero/page/Installation/
[4] http://projects.ceondo.com/p/indefero/page/InstallationScmMonotone/
-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



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

Re: [Monotone-devel] Indefero code forge with monotone support released

[Thomas Keller]

Hi Martin!

 thanks for your hard work on this. I've seen you're not just adding
 monotone support but generally improving it in other areas as well.
 Indefero looks really nice and it's very practical for (opensource)
 projects with the multiple projects approach as it allows for better
 workflow with contributors and derived projects. The 'issues' module
 and other features are great plus too. It's also slightly better for
 admins as it's written in PHP which every admin know and most likely
 already has setuped.
 
 Personally I'm using monotone since 2004 and it's my favorite DVCS for
 it's design, compactness, one of the cleanest C++ code I've ever seen.
 I like monotone so much that I consider myself a contributor, though
 I've not contributed much in code, just few bits in the past. But
 I would like to have monotone being more used and my strategy for this
 is by using in my opensource projects. It's a very long-term process
 generally, but hopefully at least one of these will reach critical mass.
 
 I've also recently looked more on GIT and some other DVCSs and I must
 say after reading about various features and workflows I'm little
 horrified about dangerous usage (like rebase), weird branching and other
 stuff. I like monotone even more since that :)
 
 Particularly it seems they're generally stuck with the idea of having
 every commit perfect, even when that requirement is not really needed in
 DVCSs. And that desire drives various weird features and workflows. Also
 I feel GIT is really a special case for Linux kernel development since
 I've never met any other project that is developed in similar fashion.

Many thanks for your warm words - our little team and especially me, we
are all appreciating this kind of feedback a lot. Thank you!

 If you want to try out Indefero with monotone support, grab the zip [2],
 follow the generic instructions to set up the base system [3] and
 finally read the instructions how to configure the monotone plugin [4].

 We'd love to get some feedback from you!
 
 I'll be setuping it within about one month so I will post my experience
 with setuping it then.

Ok, let us know if you stumble upon any kind of problem, you'll reach us
through IRC at any time (#indefero at freenode and #monotone at oftc).

Thomas.

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



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

Re: [Monotone-devel] Deciding on a date?

[Thomas Keller]

Am 20.03.11 17:53, schrieb Richard Levitte:
 Hey,
 
 I'm thinking, end of Q1 is coming near (just 10 days left!), and it
 might be time to set a date for the release.  I don't know how the
 rest of you are thinking, I'm just thinking that this close, it might
 be good to have a point in time that we know about, so none of us gets
 surprised when it happens.

Right. I'd target next Sunday for this, this weekend was indefero's one.

Sunday releases are nice in the way that people notice the release on
Mondays when they're back at work and because the release manager is not
stressed after a hard working day and therefore does not make anything
wrong in the release process.

Speaking of the release manager hat - I announced that I'd want to give
my one to another monotone fellower some time last year and Thomas
Moschny said he would took over the job, but I haven't seen him around a
lot lately (which is understandable being a young father :)), so in turn
I'd ask you, Richard, would you like to do the release? You put such a
lot work into this and I lately slacked off a lot and devoted more time
in other stuff, so I'd say its somewhat your release. I'll support you
with blogging / announcing and graphics work wherever I can, just drop
me note - what do you say?

Thomas.

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



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

[Monotone-devel] Re: [Monotone-i18n] On translations...

[Thomas Keller]

Am 19.03.11 12:41, schrieb Richard Levitte:
 Hi,
 
 I'm a bit concerned about the translations we currently say we support
 (according to po/LINGUAS).  As it is right now, here's the statistics:
 
 ...
 German:1454 translated messages,  83 fuzzy translations.
   last change: 2011-03-14 01.33.36 GMT+1

German translation is done.

 As a side note, a reminder: I understand that it's tempting to commit
 changes in po/*.po files when they get automagically updated (I've
 done that as well a few times in the past and been appropriately
 scolded for it).  Please don't, it's more confusing than helpful.  Let
 the translators do their job. Thank you.

Yes, sorry, I'm guilty here as well. I promise improvement :)

On a related note, I more and more loose faith in transifex, also
because I'm using it a bit more in another project and have only
problems with it, especially when it comes to fuzzy handling (which
seems to be literally non-existing). So far the only thing that tx
brought us were the nice graphs, but it reformats translations
differently, strips out comments everywhere (I wrote about this already
earlier, thats why I created the different README.lang files after
all) and sometimes even does not get its own statistics right (I had to
push the pot file twice to let it acknowledge the correct number of
source strings, 1537), so I'm refined and very much vote for dumping it
completely. That would also mean that we remove it from the po's README
and do not hint translators any longer towards this service and also to
remove the project on tx.

Any objections?

Thomas.

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



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

[Monotone-devel] ciabot test fails

[Thomas Keller]

Hey there!

The ciabot test fails for me in line 45, because my oldish Python
(2.5.5) throws a deprecation warning and the test assumes that stderr is
zero:

./extra/mtn-hooks/monotone-ciabot.py:113: Warning: 'with' will become a
reserved keyword in Python 2.6
  File ./extra/mtn-hooks/monotone-ciabot.py, line 113
with open(config_file) as f:
^
SyntaxError: invalid syntax

So either we work around this issue by replacing the offending code or
we skip the test in case the Python version is  2.6.

Opinions?

Thomas.

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



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

[Monotone-devel] String freeze for 1.0

[Thomas Keller]

Hi all!

I just merged the string sanitization branch back to net.venge.monotone
and officially announce a string freeze now.

This is the time for the translators to pick up the changes and finalize
their translations. The timeframe you have for this is roughly two weeks
and I hope we get as much high quality translations in until then as
possible.

I'm sorry that the merge of the aforementioned branch brought in so many
fuzzy strings for you, most of the time stylistic changes that
originated from sloppy string practises of us developers in the past.
We hope to minimize similar efforts in the future and put up a clear
guide how we want to formulate and format i18n source strings in the
future [0] - we welcome your valueable feedback on these rules!

The string freeze also means that no new development should happen in
net.venge.monotone that introduces new strings or changes existing ones.
Please postpone these things after 1.0 has been released or do your
changes in a separate branch.

Thanks for listening,
Thomas.


[0] Section Formatting messages in
https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/HACKING
-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



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

Re: [Monotone-devel] Re: Monotone - A couple quick notes

[Thomas Keller]

Am 05.03.11 06:48, schrieb Richard Levitte:
 Also, renaming of branches is really much easier since we implemented
 'mtn suspend', all you really have to do is make sure the head of your
 chosen branch gets a branch cert with the new branch name (or you
 commit something new with -b {newbranch}), suspend head of the old
 branch (the one you started from) in that old branch, and you're set
 with a new branch name, all sparkly and shiny.  The good thing with
 this is that it doesn't try to remove anything, doesn't require anyone
 to do any tricks...  in other words, it's very well supported by
 monotone.

You're right, using suspend certs make some things really easier today,
while allowing to keep the old history and branch structure intact, but
invisible. I sometimes forget their usefulness :)

Thomas.

PS: Nice article!
http://journal.richard.levitte.org/entries/monotone-branch-renaming/

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



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

Re: [Monotone-devel] Release Of Monotone Browser 0.72 And Monotone::AutomateStdio 0.12

[Thomas Keller]

Am 05.03.11 16:05, schrieb CooSoft Support:
Just a quick email to announce the release of the above software on
 source forge and CPAN respectively.
 
Basically the main work was to get these packages working with
 version 0.99.1 of Monotone.
 
Monotone Browser, not only having the new selectors introduced in
 0.99.1, also now has the ability to restrict revision and file histories
 to specific branches.

Very nice! MacPorts recipes have been updated accordingly.

Thomas.

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



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

Re: [Monotone-devel] missing branch certs?

[Thomas Keller]

Am 03.03.2011 12:49, schrieb Stephen Leake:
 There are two recent revisions that have no branch certs:
 
 5fa27bc987ed68996eb036347a5889a8bc00d681
 359246213ac107d95686f8400dcd57d074c62480

Yes, sorry, my fault. I'll push the missing certs asap.

Thomas.

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




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

Re: [Monotone-devel] Google Summer of Code

[Thomas Keller]

Am 03.03.11 02:58, schrieb Aaron W. Hsu:
 On Wed, 02 Mar 2011 18:10:25 -0500, Thomas Keller m...@thomaskeller.biz
 wrote:
 
 Applications are open again - do we want to take another shot? Deadline
 is 11th of March. We surely have lots of things to do and some more
 fresh blood wouldn't be bad either, though it gets harder and harder
 every year to be picked under so many applicants...
 
 I think it is a pretty neat idea. I might be able to recommend it to my
 students if there is something that they could do.

That would be great! To actually apply however, we need more manpower,
three people would be sufficient already (an administrator, a backup
administrator as well as at least one additional mentor).

The most important question now is however if we want to apply again.
The last application we send out was 2008 or 2009 (I can't remember
exactly), but we weren't in at that time, so the chances are low we're
in this time, but of course that doesn't mean we should not try it.

I need some more people supporting this - who's in? I would do the
administration, so we need a backup admin and at least another mentor.
Then we can start and prepare our application.

Thomas.

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



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

[Monotone-devel] Nightly coverage report

[Thomas Keller]

Hey there!

I've setup a code coverage build of nvm on my server. It is refreshed
every day at 6am here:

http://monotone.thomaskeller.biz/coverage/index.html

The overall coverage is quite good already. The report should help us
identify dead and / or untested code.

Thomas.

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




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

[Monotone-devel] Google Summer of Code

[Thomas Keller]

Hey there!

Applications are open again - do we want to take another shot? Deadline
is 11th of March. We surely have lots of things to do and some more
fresh blood wouldn't be bad either, though it gets harder and harder
every year to be picked under so many applicants...

More information about this year's GSoC can be found here:

  http://www.google-melange.com/

This is this year's schedule:


http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline


Any takes?
Thomas.

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



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

[Monotone-devel] Re: Monotone - A couple quick notes

[Thomas Keller]

Hi John!

At first - please consider subscribing to monotone-users [0] or
monotone-devel [1], you reach a much bigger audience with that. The
former is also rather low-volume, in case you care. Thanks!

Am 27.02.11 16:03, schrieb John B Thiel:
 New problem:  since the default auto-managed database was made, seems
 I cannot get --db to recognize other databases.  It keeps defaulting
 to the auto one. I seem to recall that I was able to work with a
 target --db initially (before the one in AppData was made.)
 
 For example:  Here it works to setup into my foo.mtn repository, but
 then I cannot list it.  Maybe it's just a problem with list, since the
 setup does put the right directory in the _MTN\options file.
 
 C:\Users\jbthiel\wkspaceEclipseTest\_junk\fp201HaskProjmtn --db
 c:\Users\jbthiel\foo.mtn setup --branch fp201 .  -v
 [...]
 C:\Users\jbthiel\wkspaceEclipseTest\_junk\fp201HaskProjmtn --db
 C:\Users\jbthiel\foo.mtn list db
 :default.mtn (in C:/Users/jbthiel/AppData/Roaming/monotone/databases):
 no known valid workspaces

Up until 0.99.1 only managed databases store their workspaces - this
will change in the next version. The `list databases` command also
actually does not use the global --db option at all, so it is not
needed. Furthermore, to get foo.mtn displayed in the output of `list
databases`, the database must reside in a managed path. And this can be
configured through the hook get_default_database_locations(), which
defaults to $HOME/.monotone/databases.

Hope this helps,
Thomas.

[0] http://lists.nongnu.org/mailman/listinfo/monotone-users
[1] http://lists.nongnu.org/mailman/listinfo/monotone-devel
-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



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

[Monotone-devel] Fwd: Re: Monotone - A couple quick notes

[Thomas Keller]

FYI - to keep the discussion on the list.

@Richard: I noted your reply and agree completly. Post-1.0 and
shrinked-down view that only notes the most important stuff, while
leaving other things for --full or --complete.

Thomas.

 Original-Nachricht 
Betreff: Re: Monotone - A couple quick notes
Datum: Sun, 27 Feb 2011 13:10:39 -0800
Von: John B Thiel jbth...@gmail.com
An: Thomas Keller m...@thomaskeller.biz

On Thu, Feb 24, 2011 at 1:41 AM, Thomas Keller m...@thomaskeller.biz wrote:
 Am 24.02.2011 03:35, schrieb John B Thiel:

 Another thing that might be helpful is grouping/highlighting the basic
 subset of most frequently used commands.  Generally with these systems
 you use the same basic 5-10 commands 80+% of the time, with the rest
 for special cases, but it's always some work to initially find those
 10.

 What would you propose here? I could only think of printing often used
 commands in bold (or somehow colored) in the output of `mtn help`. We
 started a colorization branch some time ago for the purpose of making
 the output of diff, log and friends easier to grasp, but I fear this
 won't get ready until 1.1, because Windows support for this is still
 largely lacking.


Conceptually, to me the bare minimum of VC is bringing content into
the repository, at which point I could safely delete the source, and
re-create it.

So maybe at the top or bottom you can have a group like 'BASICS',
'Getting Started', or 'Most Used'.

Rather than highlighting, which might be confusing (and not widely
supported in terminals), this group would duplicate commands from the
other groups - specifically, for the input side:

create db
setup/register a subdir (workspace)
add files
checkin
commit
merge
etc

and for output:

co, checkout, list
etc

Basically, the top 10 commands you all use most of the time, plus
whatever setup, and list/status commands are needed to get going.


Also, by the way, in the main help screen, if the 3 sentences at the
end were tightened up or moved to the top, then more of the commands
would stay on-screen, in a small window.

Also, I think most of the help screen phrases Commands that do xxx
don't really add much, while taking lots of space. It could just say:

Command groups:

database(db, local)
tree(checkout, co, conflicts, ...)
workspace   (add, attr, ci, commit, ...)

etc

===

Thanks for the good notes on the branch collision issues, and I
generally agree with your conservative approach.

-- jbthiel



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

[Monotone-devel] Re: Monotone - A couple quick notes

[Thomas Keller]

Am 24.02.2011 03:35, schrieb John B Thiel:
 On Wed, Feb 23, 2011 at 2:34 PM, Thomas Keller m...@thomaskeller.biz wrote:
 Saying `mtn help cmd` is just one way, another is the `--help` (or
 short `-h`) option which can be put anywhere, also at the end of the
 command sequence. `--help` and `help` are aliases in some way, just that
 you can give additional options to the help command like displaying
 hidden (debug) commands, but all visible and general purpose commands
 can just be queried with `--help` alone.
 
 
 Ah, very good!  -h at the end of the line solves just what I meant.
 
 Another thing that might be helpful is grouping/highlighting the basic
 subset of most frequently used commands.  Generally with these systems
 you use the same basic 5-10 commands 80+% of the time, with the rest
 for special cases, but it's always some work to initially find those
 10.

What would you propose here? I could only think of printing often used
commands in bold (or somehow colored) in the output of `mtn help`. We
started a colorization branch some time ago for the purpose of making
the output of diff, log and friends easier to grasp, but I fear this
won't get ready until 1.1, because Windows support for this is still
largely lacking.

 We leave command completion up to the shells and have actually improved
 the bash completion script for the upcoming version 1.0 quite a bit
 (amongst many things its source data are dynamically built from the
 command tree, so it automatically knows all the available completions).
 There is also a zsh completion script in our tree, but this just needs a
 little more love and might be slightly outdated.
 
 This is a script/alias that one loads into the bash shell?  A good
 approach; where do I find it?

For the current version these are the files
monotone.{bash,zsh}_completion here:

https://code.monotone.ca/p/monotone/source/tree/t:monotone-0.99.1/contrib

The new magic one however is only available in the trunk and needs to be
built from source to work properly:

https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/extra/shell

Give us some more time - we plan to release 1.0 which ships with the new
one by default by the end of March.

 * Globally unique branch names
 [...]
 So can the top-level branch just start out as a word, like
 Wondermatic, and then a release branch can be Wondermatic-1.0.
 Or should one preferably use tags, or revision ids to track releases?
 I am not sure yet how branches, tags, and revisions fit together.

If you start out with Wondermatic in your private development, then
this is just fine. Be careful though that whenever you go public with
that, that there is the chance that the branch name is not unique and
lead to confusion. While it is possible to rename the branch in a
complete private history later on, its still a bit harder than for
example in git, because every single revision needs to loose its old
branch certificate and gets a new one attached.

The hierarchical setup is actually quite nice for a couple of other use
cases, like pushing or pulling changes to and from somewhere. For
example, if you happen to have the branches

Wondermatic
Wondermatic-1.0
Wondermatic-1.1
Wondermatic-Website

and you now only want to sync the trunk and stable branches, you have to
--exclude Wondermatic-Website specifically. If you however choose to
name them

Wondermatic
Wondermatic.releases.1.0
Wondermatic.releases.1.1
Wondermatic-Website

the include pattern would simply be Wondermatic{,.*}. Of course this
works with any other separator than . as well, as long as it is not
some reserved character.

 Is it fine if the branch and workspace directory have the same name?

This is fine - but you can also use a completly different name. This
doesn't matter actually much nowadays, because `mtn list databases` will
always print you what workspaces have what branch currently set up. If
you happen to work with many branches and switch between branches very
often, its probably more fitting to just name the workspace after the
name of the project or the common (hierarchical) branch name.

 Surely it can't matter
 if Frank in Kalamazoo *also* has a Wondermatic branch like me ?
 unless I ever started working with him, I guess?  And tried to put his
 project in my same repository?  Then what? can't he or I just somehow
 rename colliding branches at that point ?   Or I just make a new --db
 repository to hold that project separate from my others ?

Picking the colliding branches once they are in the same database is
quite hard, because the way revisions are selected depends very much on
the certificates that are tacked on them and especially for the netsync
/ network use case you can only select revisions by branch name, not by
author, date, changelog or anything else.

Please keep also in mind that distributed systems are bad at purging
unwanted data, so even if you or he is locally renaming his project tree
to another name - once he has synced his changes

Re: [Monotone-devel] Re: Monotone - A couple quick notes

[Thomas Keller]

Am 24.02.11 08:43, schrieb Stephen Leake:
 Thomas Keller m...@thomaskeller.biz writes:
 Saying `mtn help cmd` is just one way, another is the `--help` (or
 short `-h`) option which can be put anywhere, also at the end of the
 command sequence. 
 
 Cool! I never realized that. I've added a short mention of this in the
 manual. 

Thanks! By the way - the --help option is no different from any other
option, so it not only can be placed up front or at the very end, but
also in the middle of a command (as long as its before `--` which stops
option parsing), so something like `mtn ls --help changed` is possible
as well, though probably not that useful.

 The manual could be clearer about this; globally unique names are not
 _required_, they are just a good idea.
 [...] 
 I've improved the section on branch names with this.

Looks good, many thanks!

Thomas.

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



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

Re: [Monotone-devel] Contradiction in Makefile.am

[Thomas Keller]

Am 23.02.2011 07:42, schrieb Richard Levitte:
 I just had a closer look at the NLS support in Makefile.am, and I'm
 finding this (dist-nls used to be dist-local until that one needed
 expanding):
 
 ...
 CLEAN_POFILES := $(ALL_GMOFILES) \
$(addprefix po/,$(addsuffix .merged.po, $(ALL_LINGUAS))) \
po/$(PACKAGE).pot
 ...
 dist-nls: $(ALL_GMOFILES)
   cp $(ALL_GMOFILES) $(distdir)/po
 ...
 
 
 Now, I don't know about you, but to me, it seems contradictory to have
 the .gmo files be part of the distribution, but then have them wiped
 with 'make clean'.
 
 So, how shall we have it?  What's the reason for .gmo files to be part
 of the source distribution?  Or, if they really should be (I'm sure
 there is a good justification), why are they part of things to be
 cleaned with 'make clean'???

For me it sounds wrong to have the gmo files compiled in the tarball,
but there might have been a good reason why this has been the case in
the past. If there are no strong objections I'm all for removing the gmo
files from dist.

Thomas.

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




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

[Monotone-devel] Re: Monotone - A couple quick notes

[Thomas Keller]

Am 23.02.11 18:41, schrieb John B Thiel:
 Hello, I was just taking a quick look at Monotone, which looks very
 well-designed and excellent, with some great features (I especially
 like the single file repository, xdelta, and robust design).  A couple
 first 5 minutes feedbacks:

Hi John!

Many thanks for your feedback! I hope its ok that I share it with the
others... I'll answer item for item.

 * Allow 'help' at End of line
 
 The builtin 'help' is great, but it should allow saying help at the
 END of a command sequence (complete or partial).  The current design
 requires shuttling back and forth to the beginning of commands you are
 building up to keep inserting and removing the word 'help' - very
 annoying.

Saying `mtn help cmd` is just one way, another is the `--help` (or
short `-h`) option which can be put anywhere, also at the end of the
command sequence. `--help` and `help` are aliases in some way, just that
you can give additional options to the help command like displaying
hidden (debug) commands, but all visible and general purpose commands
can just be queried with `--help` alone.

 One of the nicest designs for this kind of command-tree
 interface is a dynamic readline that offers listing and
 auto-completion of the available commands depending on what node you
 are at so far,  and quick help at that node by typing '?' (or 'help'),
 then you type the next parameter, etc.Until Monotone might acquire
 such a readline, supporting 'help' at the end would at least allow
 more efficient use of shell recall.  (also, if the command is
 incomplete when entered, it could list the valid options at that
 point).

We leave command completion up to the shells and have actually improved
the bash completion script for the upcoming version 1.0 quite a bit
(amongst many things its source data are dynamically built from the
command tree, so it automatically knows all the available completions).
There is also a zsh completion script in our tree, but this just needs a
little more love and might be slightly outdated.

 * Globally unique branch names
 
 The part in the manual 1.7.2 about requiring globally unique branch
 names is highly disconcerting and does not fit the generally robust
 presentation and positioning of Monotone.  I did not even want to
 bother with a branch name at all on an initial trial setup, but it was
 apparently required, and then to find they have to be globally unique,
 extralong strings linked to some other random construct  (DNS?? what
 does that have to do with my project files?) 

monotone is all about global identity and it wants you to ensure that
you put your contents (files and revisions) in a namespace that cannot
be accidentially confused by somebody else and that you can always
recognize wherever it is put. monotone can, by design, host many
different projects in one single repository and without a clear branch
naming it would be impossible to distinguish these different projects
from each other.

You are of course free to choose whatever branch you like for your
project, monotone won't hinder you to use master or develop or
anything else. It is just a little pickier recently about certain
characters allowed in the branch, for the reason that some of them might
otherwise conflict with special characters used in branch patterns or
monotone URIs. Be aware though that whenever your repository contains
two different projects with the same branch name, that you'll have a
hard time selecting and thus for example querying, logging, committing
and merging revisions.

 Also, the manual cannot
 just nonchalantly throw out passages like bad things can happen.  I
 hope this is an area that can be reworked -- why should the user have
 to explicitly name branches in the first place, and requiring global
 uniqueness is not reasonable, and if pushing this burden to the users,
 the manual should at least detail exactly what kind of bad things
 will happen and how to recover from them.

Thanks for that - we're looking into the documentation and try to
improve that.

 * I could not get unregister_workspace to remove a  workspace (from an
 auto-managed db).  It just silently does nothing. This is on Windows7.
  Any tips on the syntax?  I tried full pathname with both fwd and
 backslash, exact capitalization, and also tried a '~' reference.  If I
 remove/rename the _MTN dir and do cleanup_workspace_list, then it goes
 away (as reported by list db).

mtn unregister_workspace can work with and without a given workspace
path (if none is given, the current workspace is used). I don't know of
problems with this particular command, but then, on the other hand,
we're currently low on Windows build bots. Would you mind and send us
the output of the command with an appended -v?

 Thanks for the excellent work on Monotone!

Thank you for your feedback!

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, 

Re: [Monotone-devel] Soon time for a release

[Thomas Keller]

Am 22.02.11 23:58, schrieb CooSoft Support:
One thing, mainly for my stuff, is has there been any automate stdio
 changes made since 0.99.1? I had a quick look at the nightly doc stuff
 and couldn't see anything obvious. I aim to release the MAS library and
 mtn-browse at 1.0 roughly at the same time.

The only major change in automate is that it now runs by default with
LANG=POSIX, so in case you haven't already set this manually before
calling stdio, there shouldn't be anything which affects mtn-browse.

My revision graphing module will have to wait until 1.1 of mtn-browse
 :-(.

I had a quick look over your code on the forge and would say you already
have some nice functionalities in there (especially the graph connection
code). My implementation is far simpler and probably also more buggy,
but I basically have the same timing problem. Maybe I'm also simply not
in the mood for Qt and / or guitone right now :)

Thomas.

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



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

Re: [Monotone-devel] Soon time for a release

[Thomas Keller]

Am 22.02.11 15:27, schrieb Richard Levitte:
 Hey there,
 
 Some time furign the winter (when we realised a Christmas release
 would be impossible), we said that we would release monotone v1.0
 withing Q1 2011.  Q1 ends in a little more than a month (*), so it
 might be time to wrap it up a bit.
 
 The things I see left to do is this:
 
 1. have a look at the open issues, try to classify the issues in
milestones they should go into or simply fix them if it seems
appropriate.

I think the issues listed under

https://code.monotone.ca/p/monotone/issues/label/399/open/

are (at least for me) the only dealbreakers for 1.0. We have of course
more bugs in the tracker, but I think most do not qualify to hold 1.0 back.

Personally there is only one more ticket, which is actually a regression
from 0.48 iirc, that is nagging me a bit, issue 132. Its not yet
targeted for 1.0 and I'd be ok if it goes into 1.1 or later as well.

 2. go through the contrib/ directory and see what can and should be
moved to somewhere in extra/, be moved somewhere else (the wiki
on a 'tricks and tips' or 'contributed stuff'?), or tossed.
If you want to toss something, please talk with the original author
first.

You've been very busy in this area lately - thanks a bunch for all your
work! If we don't manage to move most of the contrib/ stuff, then I'm
all for removing it temporarily from the distribution and bring it back
step by step in the upcoming releases. Until then it can peacefully
co-exist just in the source tree.

 3. at some point, we will create a separate branch for v1.0, probably
named like the others, i.e. net.venge.monotone.monotone-1.0, and
have that be frozen for changes except for serious bugs.

+1

 4. general check that it works on as many systems as possible.

I hate to ask, but I guess we still have no news on the buildbot front,
right? I need to kick-off the openSUSE stuff again...

 Did I forget something?  Please add to the list.

Just a note about the string unification - I'm all with you here. I'll
start with the placeholder unification tonight. Need some easy work,
I recently catched a cold, I hope I'm better by the end of the week.

Thomas.

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



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

Re: [Monotone-devel] problem with denied permissions

[Thomas Keller]

Am 21.02.2011 11:07, schrieb Martin Bruse:
 Hello, I don't subscribe to this list, so please reply directly to me if
 you have any helpful hints :)
 
 Today when I tried to sync with my usher at home, I got a denied read
 permission for something that worked perfectly fine a couple days ago.
 
 I have now simplified the case slightly by removing usher from the
 equation, and this is what it looks like now:
[...]
 [0:zond@snort ~]$cat .monotone/monotonerc
 
 function get_netsync_read_permitted (collection, identity)
 if (identity == mar...@menyou.se mailto:mar...@menyou.se) then
 return true end
 ...
 return false
 end

identity is no longer a string, but a table. This is documented in the
section Common data types here:

http://www.monotone.ca/docs/Hooks.html#Hooks

We try to minimize these kinds of dealbreakers during the 1.0
maintenance. And while the aforementioned change was noticed in NEWS,
these kinds of things tend to vanish in the vast amount of changes
from release to release.

Sorry for the inconvenience.

Thomas.

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




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

Re: [Monotone-devel] question about monotone serve

[Thomas Keller]

Am 26.12.10 01:50, schrieb Thomas Keller:
 Am 25.12.10 20:32, schrieb Hugo Cornelis:
 Hi all,


 I am trying to start a monotone server on port 4704, listening on all local
 network interfaces.  But monotone complains about the syntax of the bind
 command line argument.

 This is the command line I use:

 $ mtn --db /home/cornelis/neurospaces_project/MTN/rtxi.mtn serve
 --bind=:4704
 mtn: misuse: unable to parse host of URI ':4704'
 
 This pops up because of a stupid workaround from me in
 network/connection_info.cc:527 (setup_for_serve) - Aaron is right,
 0.0.0.0:4691 should work in the meantime. Issue 119.

This has been fixed in 05b4d62389d9d181f188ce73e76c6d859f7a5eb3. Sorry
that it took so long.

Thomas.

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



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

[Monotone-devel] Re: transifex and initial comments in the message catalogue

[Thomas Keller]

Am 16.02.11 00:10, schrieb Thomas Keller:
 [...] My proposal now is two-fold:
 
 1) Add a README file for every translation (i.e.
 po/README.de) and let the author add the copyright(s) and
 optional translation hints
 
 2) Place a proper comment into the uploaded po/monotone.pot with a
 general copyright text and the hint that the file is copyrighted to the
 entities and under the terms written down in po/README.lang

This has been committed in 39a49c3e46416a078e464a3a713505c6cff69d5b -
please check if I got your copyrights right in the individual README files:

http://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/po

and please also read over po/README, which I adapted slightly as well.

Thomas.

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



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

Re: [Monotone-devel] contrib stuff

[Thomas Keller]

Am 10.02.2011 07:40, schrieb Stephen Leake:
 I suggest we delete mtn_cheat_sheet.svg; it's incomplete, broken, we
 don't have the source, the copyright/license is unclear.

The SVG is the source, I did it in 2007 with Inkscape. I was too lazy in
the past to redo it nicely. Eventually I thought some graphics guy would
drop in and make it look awesome, but that never happened. So I'm ok
with you deleting it. Its incomplete and outdated and should therefor
not be shipped.

Thomas.

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




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

Re: [Monotone-devel] question about how a selective log displays head nodes

[Thomas Keller]

Hi Hugo!

Am 06.02.11 10:44, schrieb Hugo Cornelis:
 We are maintaining documentation in a monotone repository.  In the
 workspace on my laptop I invoke:
 
 $ mtn automate heads
 970f659a5173b3b0183ab4a70986a033ce107cf1
 
 So I assume the branch (name: 0) has only one head.
 
 There is a document I am working on, it is called
 cbi-scripting/cbi-scripting.tex and it is under monotone control.
 
 Within xemacs I invoke the following shell command from the root
 directory of the local workspace:
 
 mtn log --last 100 cbi-scripting/
 
 which gives (abbreviated output of the first N revisions, removed the
 ChangeLog entries, a fixed width font should show the bars lined up) :
 
 o-.-.-.-.-.-.-.-.-.-.-.-. (Revision:
 970f659a5173b3b0183ab4a70986a033ce107cf1)
 |\ \ \ \ \ \ \ \ \ \ \ \ \
 | | | | | | | o | | | | | |
 --
 | | | | | | | | | | | | | |   Revision: 
 5b43131aa22834ed673de98d76f6d02c5534ef8c
 | | | | | | | | | | | | | |   Parent:   
 37aae4e7b9dbfa330887fe347d9dd7b08e52935a
 | | | | | | | | | | | | | |   Author:   allan.c...@gmail.com
 | | | | | | | | | | | | | |   Date: 02/04/11 19:07:29
 | | | | | | | | | | | | | |   Branch:   0
 | | | | | | | | | | | | | |
 | .-.-.-.-.-.-o-.-.-.-.-. |   (Revision:
 37aae4e7b9dbfa330887fe347d9dd7b08e52935a)
 |/|/|/|/|/|/|/ \|\|\|\|\|\|
 | | | | o | |   | | | | | |
 --
 | | | | | | |  / / / / / /Revision: 
 3e989d56fd4c6d57ebc072c5e7a0553d42a3ab7c
 | | | | | | | | | | | | | Parent:   
 bedcaca085c7ef926f6639c7e996446bdd30f0fb
 | | | | | | | | | | | | | Author:   allan.c...@gmail.com
 | | | | | | | | | | | | | Date: 02/04/11 18:55:12
 | | | | | | | | | | | | | Branch:   0
 | | | | | | | | | | | | |
 | .-.-.-o-.-.-.-.-.-.-. |   (Revision: 
 bedcaca085c7ef926f6639c7e996446bdd30f0fb)
 |/|/|/|/|\|\|\|\|\|\|\|\|
 | | o | | | | | | | | | |
 --
 | | | | | | | | | | | | |   Revision: 2990057caa0ee1ce90aeb46e19c2065654d49108
 | | | | | | | | | | | | |   Parent:   9fbbed811348bea34687d3acb12d155ce0bc3b55
 | | | | | | | | | | | | |   Author:
 mandorodriguez+ubuntu.vm.home.i...@gmail.com
 | | | | | | | | | | | | |   Date: 02/03/11 07:51:03
 | | | | | | | | | | | | |   Branch:   0
 | | | | | | | | | | | | |
 | | o | | | | | | | | | |
 --
 | | | | | | | | | | | | |   Revision: 9fbbed811348bea34687d3acb12d155ce0bc3b55
 | | | | | | | | | | | | |   Parent:   54d833b5c9b9e7e649096fa6ee52be3b724836e1
 | | | | | | | | | | | | |   Author:   mandorodrig...@gmail.com
 | | | | | | | | | | | | |   Date: 02/02/11 23:33:48
 | | | | | | | | | | | | |   Branch:   0
 | | | | | | | | | | | | |
 | | | | | | | | | | | | | o
 --
 | | | | | | | | | | | | | |   Revision: 
 cd3ecf3fc142b98b457aba8df5795c884e74147e
 | | | | | | | | | | | | | |   Parent:   
 7cce4fde1c40c4252d24488c7f2171a7c259e3fc
 | | | | | | | | | | | | | |   Author:   mandorodrig...@gmail.com
 | | | | | | | | | | | | | |   Date: 02/02/11 00:47:06
 | | | | | | | | | | | | | |   Branch:   0
 | | | | | | | | | | | | | |
 | | | | | | | | | | | | | o
 --
 | | | | | | | | | | | | | |   Revision: 
 7cce4fde1c40c4252d24488c7f2171a7c259e3fc
 | | | | | | | | | | | | | |   Parent:   
 9a2816511d9ce21cb246affbbd4f7156a567fa63
 | | | | | | | | | | | | | |   Author:   mandorodrig...@gmail.com
 | | | | | | | | | | | | | |   Date: 02/01/11 20:30:52
 | | | | | | | | | | | | | |   Branch:   0
 | | | | | | | | | | | | | |
 | .-.-.-.-.-.-.-.-.-.-o-. (Revision:
 9a2816511d9ce21cb246affbbd4f7156a567fa63)
 
 etc...
 
 In this output both Revision: 970f659a5173b3b0183ab4a70986a033ce107cf1
 and Revision: cd3ecf3fc142b98b457aba8df5795c884e74147e are listed as
 heads.
 
 I then invoke:
 
 
 $ mtn log --revision 54d833b5c9b9e7e649096fa6ee52be3b724836e1
 o   --
 |   Revision: 54d833b5c9b9e7e649096fa6ee52be3b724836e1
 |   Parent:   cd3ecf3fc142b98b457aba8df5795c884e74147e
 |   Author:   mandorodrig...@gmail.com
 |   Date: 02/02/2011 09:35:10 PM
 |   Branch:   0
 |
 
 which lists cd3ecf... as its parent revision.  So clearly cd3ecf... is
 not a head.
 
 I would have expected that the selective log format would insert
 additional revision records between parenthesis when needed to prevent
 confusion about ancestry of the displayed revisions.  So I am
 surprised that the selective log format displays cd3ecf... as a head
 node.
 
 Is this to be expected?

Yes, it is since 0.99. 0.48 had a couple of bugs concerning path
restrictions especially within mtn log - basically the other way you're
heading to: Previously parent revisions have always 

Re: [Monotone-devel] What's Up With code.monotone.ca?

[Thomas Keller]

Am 05.02.11 11:03, schrieb CooSoft Support:
Seems to be having a senior moment... I get
 https://code.monotone.ca/p/monotone/source/disambiguate/h:net.venge.monotone/from/IDF_Views_Source::treeBase/
 
 when I got to the monotone project
 
Other projects don't seem to be affected.
 
Just thought I would let someone know...

This is just displayed in case the branch in question is unmerged. You
can click on either revision and continue as normal.

Thomas.

PS: The branch should be merged again.

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



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

Re: [Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Am 04.02.2011 10:14, schrieb Richard Levitte:
 me * make distcheck prints out a spurious warning at the beginning:
 me make[1]: Circular htmldir - html dependency dropped.
 me   Can this be safely ignored or is this something we should look after?
 me   (Its issued right after makeinfo --html)
 
 Hmm, I don't get that.  Does that happen when you build in the source
 directory?

This happens when I ran make distcheck in the source directory and is
part of the output of the make process which builds from the source
tarball. I can give you more specifics when I'm back home - its in the
console there :)

Thomas.

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




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

Re: [Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Am 31.01.11 00:08, schrieb Thomas Keller:
 So please have a look at the changes in this branch and give us
 feedback. If you think it is not a good idea to merge this into nvm yet,
 then please also tell us. In case nobody places serious objections I'd
 like to merge the branch by the end of next week (Friday'ish).

Richard, Steve and me worked out the remaining issues, so that I could
finally merge the branch back into nvm. Before you update please run
make distclean on an existing workspace so that all the old cruft is
gone and start anew with autoreconf -i.

Thomas.

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



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

Re: [Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Am 03.02.2011 07:08, schrieb Stephen Leake:
 Thomas Keller m...@thomaskeller.biz writes:
 
 There are a couple of minor issues left which kind of block the merge
 back to nvm, one of them is the move of some innosetup-specific
 resources out of src/win32 
 
 I'm not clear what the issue is here. In any case, 'make
 win32-installer' now works, does that resolve it?

It was merely a little nuisance - we have the installer files in
src/win32, but they are actually not source, but deployment-specific
files. This is inconsequent insofar we have other distibution-specific
files also not under src/, for example visualc/, mac/ and the like.
Richard and me talked about that earlier on IRC and we agreed that the
innosetup files deserve their own top level directory.

 and another one deals with HTML documentation. 
 
 I'm not clear what the issue is here. In any case, 'make html' now
 works, and builds both doc/monotone.html and doc/html/*, does that
 resolve it?

Richard and you did a lot in this respect and probably fixed the issue
in the meantime. I'll review the latest changes later on, I was a bit
busy over the last couple of days...

Many thanks for all your work, Stephe and Richard!

Thomas.

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




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

Re: [Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Am 03.02.11 13:43, schrieb Stephen Leake:
 Stephen Leake stephen_le...@stephe-leake.org writes:
 
 The non-source files for building the win32 installer are modpath.iss,
 monotone.bmp, and monotone.iss.in. There is also related code in
 Makefile.am.

 ...

 I'm not strongly opposed to moving those three files to
 root/win32_install (do you have a suggested name?), but I don't see
 the consistency argument. 
 
 Perhaps the argument is files in root/src/... are source for the
 executable, not anything else. Similarly, files in root/doc are
 source for the documentation. That makes sense.
 
 Then we could have files in root/packages/... are source for
 distribution packages and/or installers (except Makfile.am goes where
 the autotools need it). Then we could have:
 
 root/packages/mingw/   3 win32 installer files 
 root/packages/cygwin/  1 cygport file
 root/packages/visualc/ renamed from root/visualc
 root/packages/mac/ renamed from root/mac
 root/packages/debian/  debian stuff
 ...
 
 I'm not clear if visualc and mac are packages (and thus similar to
 *.iss), or build tools (and thus similar to Makefile.am). Either way,
 I suggest they belong in root/packages.
 
 Perhaps root/distros instead of root/packages.
 
 It might be good to add some of the rationale for the directory tree to
 HACKING. But I guess it's pretty clear (I did figure it out with only a
 little thought :).

Lets do it simple, lets name it innosetup. I don't think a packages/
tree is a good idea, because as you already said, not everything about
packages - the visualc files for example just contain the needed stuff
for a different build environment.

I also hunted for a general top-level directory for all these things at
first, but I have to admit that this wish was merely driven to make it
really look perfect, but it doesn't actually buy us that much. The
most important things for me in this branch are actually the sane src/
and test/ setup. The doc/ cleanup is already a plus.

Another thing which lately landed on our todo was the contrib/ cleanup
[0]. This will consume lots of time and given the fact that we want to
come to an end some time we might even think about moving it to later
if it turns out to be too much work (Q1 ends in roughly 8 weeks). Again,
a question of perfectionism...

Thomas.

[0] http://article.gmane.org/gmane.comp.version-control.monotone.devel/18657

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



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

Re: [Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Am 03.02.11 10:09, schrieb Thomas Keller:
 I'll review the latest changes later on, I was a bit
 busy over the last couple of days...

Here we go:

* A make clean in the source directory now purges the original files as
  it makes no difference if these reside in the source or build
  directory. We might need some extra logic there and loop over
  CLEANFILES and only remove those that are not in $srcdir. Or is there
  a better way?

* I removed the removal of doc/*-specific resources in the main
  Makefile.am's mostlyclean-local - I think this is probably done more
  cleanly in doc/Makefile.am now.

* doc/Makefile, doc/html and doc/monotone.html are now ignored as well.

* make distcheck prints out a spurious warning at the beginning:
make[1]: Circular htmldir - html dependency dropped.
  Can this be safely ignored or is this something we should look after?
  (Its issued right after makeinfo --html)

make distcheck still runs for me, but looks good so far. I'll report
more in case of problems later on.

Thomas.

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



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

Re: [Monotone-devel] Checking on stackoverflow.com

[Thomas Keller]

Am 03.02.11 17:56, schrieb Lapo Luchini:
 I'm not using this RSS feed to check for new questions tagged monotone
 on stackoverflow.com:
 
 http://quickmediasolutions.com/stack2rss/stackoverflow/questions?tagged=monotonebody=true
 
 If anybody here has the habit of using feed to watch stuff too, it might
 we worthy to add this one (expect very low traffic).

I'll add this to my Google front page - in case something pops up. This
is - btw - the official feed:

http://stackoverflow.com/feeds/tag/monotone

Thomas.

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



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

Re: [Monotone-devel] Checking on stackoverflow.com

[Thomas Keller]

Am 03.02.11 18:48, schrieb Richard Levitte:
 Should we add this feed to the agregation on www.monotone.ca?

Better not, I'd like to keep this specific part authored, also because
we provide a news feed ourselves based on this aggregation, so
unauthored stuff could land there as well and might be off-topic or even
misunderstood.

We could, however, make a separate page / aggregation which combines
several external feeds (twitter, Y!, stackoverflow, whatever...) and
call it they speak about us or something.

Thomas.

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



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

Re: [Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Am 04.02.11 01:06, schrieb Thomas Keller:
 * I removed the removal of doc/*-specific resources in the main
   Makefile.am's mostlyclean-local - I think this is probably done more
   cleanly in doc/Makefile.am now.

This was probably a mistake, because distcheck reports at the very end

ERROR: files left in build directory after distclean:
./doc/html/_002d_002dauthor.html
[...many files...]

I'll investigate this further tomorrow.

Thomas.

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



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

[Monotone-devel] nvm.source-tree-cleanup

[Thomas Keller]

Hi all!

Richard, Stephe and me polished the above branch over the last weeks and
got positive response from a couple of people that it works well for
them. For those who weren't following the previous development, this
branch is basically about moving stuff around into specific directories,
i.e. we now have a dedicated src/, test/ and doc/ directory and the
in-tree documentation has been sanitized accordingly.

There are a couple of minor issues left which kind of block the merge
back to nvm, one of them is the move of some innosetup-specific
resources out of src/win32 and another one deals with HTML
documentation. I'd still put the whole branch up for review now already
because I really want to see the work merged back in nvm to get even
more feedback and also to allow third parties (debian for example) adapt
their source trees according to our Makefile.am changes.

So please have a look at the changes in this branch and give us
feedback. If you think it is not a good idea to merge this into nvm yet,
then please also tell us. In case nobody places serious objections I'd
like to merge the branch by the end of next week (Friday'ish).

Many thanks!
Thomas.

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



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

Re: [Monotone-devel] policy for FIXME stuff in wiki?

[Thomas Keller]

Am 23.01.11 13:30, schrieb Stephen Leake:
 The wiki has several things that look like FIXME comments:
 
 For example, in ReferenceCard.mdwn [...]

Unless somebody worked on this recently (and with recently I mean for
the last 12 months), I'm all for removing these things altogether.
Especially the referenced page contains no information which are of any
use to do something like this. If at all this looks more like a feature
request and somebody might consider adding an entry in the issue tracker
for that. But given the fact that we still have no graphic wiz around,
it will reside there unworked for long as well.

So yes, please go ahead.

Thomas.

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



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

Re: [Monotone-devel] http://wiki.monotone.ca/ vs mtn://code.monotone.ca/monotone-web?net.venge.monotone.web*

[Thomas Keller]

Am 26.01.2011 03:08, schrieb Stephen Leake:
 Thomas Keller m...@thomaskeller.biz writes:
 PS: Out of interest - why was SelfHostingInfo removed? There is still a
 link to it from monotone's website...
 
 I renamed it to MonotoneProjectServer; seemed like a much better name.
 
 Now fixed in nvm.web.mainsite. I hope that's pushed to the actual web server?

Now it is - this was one of the two setups as well where we had no
update-on-sync script running. Its now merged and updated every 10
minutes just like the wiki. Maybe Richard can look into setting up some
lua hook for both setups some time, so we can get rid of the cron jobs.

Thomas.

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




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

Re: [Monotone-devel] configure vs monotone.iss

[Thomas Keller]

Am 26.01.2011 09:52, schrieb Stephen Leake:
 Stephen Leake stephen_le...@stephe-leake.org writes:
 
 In MinGW, configure is failing to find ISCC.exe, even though it is on
 PATH; both on main and in nvm.source-tree-cleanup. 
 
 This is now fixed. The problem was the autoconf variable
 ac_executable_extensions was not being set; there does not appear to be
 any AC macro that sets it in the MinGW version of autoconf 2.67. So I
 just set it directly.
 
 Specifying ISCC by hand shows other problems in the win32-installer
 build. I'll work more on this later.
 
 'make html' ends up rebuilding the .png files, even though they are in
 mtn. This fails on MinGW, because we don't have ps2eps.
 
 in main, 'make html' succeeds on MinGW. 
 
 I'll see if I can figure out the difference.

Richard is working on this; basically the issue is that we cannot easily
add custom dependencies to certain doc build targets without adding them
to all doc targets. On mainline we use a hand-woven HTML target and not
the automake defaults, but on the long run it might be better to use the
latter.

Thomas.

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




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

Re: [Monotone-devel] http://wiki.monotone.ca/ vs mtn://code.monotone.ca/monotone-web?net.venge.monotone.web*

[Thomas Keller]

Am 25.01.2011 15:07, schrieb Stephen Leake:
 There seems to be a disconnect between http://wiki.monotone.ca/ and
 mtn://code.monotone.ca/monotone-web?net.venge.monotone.web* .
 
 For example, in the database, there is no file SelfHostingInfo, but
 there is on the web page.
 
 Similarly, I just added CVSPhrasebook.mdwn, and a link to it from
 index.user, but that's not on the web page.

Unfortunately the wiki setup is not yet auto-updated from check-ins.
I'll setup a cron job that manually calls build.sh in the meantime until
Richard can work on this.

Sorry for the inconvenience, the contents should now be in-sync.
Thomas.

PS: Out of interest - why was SelfHostingInfo removed? There is still a
link to it from monotone's website...

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




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

Re: [Monotone-devel] configure vs monotone.iss

[Thomas Keller]

Am 25.01.2011 15:28, schrieb Stephen Leake:
 In MinGW, configure is failing to find ISCC.exe, even though it is on
 PATH; both on main and in nvm.source-tree-cleanup. 
 
 Specifying ISCC by hand shows other problems in the win32-installer
 build. I'll work more on this later.
 
 Otherwise, nvm.source-tree-cleanup passes all tests on MinGW.

Many thanks for the review!

Thomas.

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




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

Re: [Monotone-devel] Bug and Fatal Error

[Thomas Keller]

Am 22.01.11 04:21, schrieb Aaron W. Hsu:
 Hello,
 
 I am reporting the following error when I call monotone incorrectly with
 the following command in a workspace:
 
 $ mtn push -b branch
 mtn: fatal: error: option.cc:462: I(!is_cancel)

This is an interesting corner case of the new option name completion
code which appeared in 0.99. The b of -b is tried to be completed
and since push has no other options that start with b, it only matches
the global option builtin-rcfile, which is the cancel version of
no-builtin-rcfile.

I see several different solutions for this nuisance:

1) Remove the invariant there, i.e. allow single letter options
   be completed to cancel options
2) Only complete on --b, but not on -b
3) Only complete when at least two letters are given

Has anybody preferences?
Thomas.

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



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

[Monotone-devel] Re: [Monotone-users] Missing root conflicts

[Thomas Keller]

Am 22.01.11 07:12, schrieb Aaron W. Hsu:
 Hello,
 
 How can I fix a missing root conflict? Specifically, it appears that I
 have two histories for a single branch:
 
 A1   A2
  ||
  oo
  |   / \
  o  o   o
  \ /
   o
 
 I wish to merge these two, but I get the following error:
 
 mtn: 2 heads on branch '---'
 mtn: merge 1 / 1:
 mtn: calculating best pair of heads to merge next
 mtn: [left]  443bbee8302f4f2b9415755ad70d65421293f8c1
 mtn: [right] ce3f4f6e5ef8a261df438a6a5f5c01c4f185e5a8
 mtn: conflict: missing root directory
 mtn: conflict: duplicate name '' for the directory ''
 mtn: added as a new directory on the left
 mtn: added as a new directory on the right
 mtn: misuse: merge failed due to unresolved conflicts
 
 I think this is because two root directories have been added. However, I
 cannot figure out how to use pivot_root to fix this. Does anyone have a
 suggestion?

I'd try it with merge_into_dir - but if that does not work I think the
best solution is to get rid of the other tree in your branch. So either
suspend the head(s) when you already synced them somewhere or remove the
wrong branch cert from the other tree and eventually merge in the wanted
changes by hand.

Thomas.

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



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

Re: [Monotone-devel] Case on Mac OS X

[Thomas Keller]

Am 20.01.11 20:58, schrieb Mando Rodriguez:
 Hi All,
 
 Recently upgraded to monotone 0.99.1 (base revision:
 8973482283db7c36780dce2b54721ccc0f5b7388) on Mac OS X (Snow Leopard). I
 attempted to update a workspace from a new sync that contained the
 renaming of a directory  from:
 
 glue/swig/python_old/heccer
 
 to
 
 glue/swig/python_old/Heccer
 
 With only the case of the first letter of the directory 'heccer'
 changing from lowercase to uppercase. Monotone bails out claiming that
 the directory already exists.
 
 mtn: updating along branch '0'
 mtn: selected update target 2898afd0a666f80d05f479d2f9d9d65d50e7c326
 mtn: [left]  1f09160cf4ba710e1afbc64b56d8cd2702dc6bc3
 mtn: [right] 2898afd0a666f80d05f479d2f9d9d65d50e7c326
 mtn: adding glue/swig/python_old/Heccer
 mtn: misuse: rename target 'glue/swig/python_old/Heccer' already exists
 
 Is there an option I need to switch on to have it handle this? Or is
 this a bug in Mac OS X?

Apple's default file system, HFS+, is case insensitive and monotone is
currently bad at handling case (in)sensitiveness, on Mac as well on
Windows. The reason is simply that the file system reports for both
paths, the old and the new, that the file exists and we cannot do much
about that.

Two possible fixes come into my mind here - one would be to
temporarily rename heccer to something else, commit and then rename it
from that to Heccer. This is a bit ugly because it creates unneeded
history. The other is to manually change the workspace' parent revision
in _MTN/revision to the new, anticipated revision, removing
glue/swig/python_old/heccer and to mtn revert
glue/swig/python_old/Heccer. If more files changed, these needs to be
reverted as well, since they could otherwise be accidentially
committed as reverse changes.

Thomas.


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



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

Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?

[Thomas Keller]

Am 09.01.11 12:34, schrieb CooSoft Support:
 I have probably completely misunderstood but...
 
 If I understand you correctly your multimap would store the raw output
 of the diff. Could one not store the essential arguments to the
 dump_diff() call instead of the diff output (say the two paths and file
 ids but _not_ the file content (which can easily be retrieved when
 needed))? Then iterate through your sorted multimap calling get_data(),
 lua.hook_get_encloser_pattern() and lastly dump_diff(). That way each
 node in the multimap would contain a lot less data than a diff output,
 addressing Richard's concern, and it would also mean that you wouldn't
 have to worry about capturing the output of external diff operations as
 they would be done in order and not require sorting.

Right, I could create a small temporary struct for that, I just hope I
don't go tabula rasa with the other code around. Lets see how it works
out - thanks for all your input.

Thomas.

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



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

Re: [Monotone-devel] The everlasting release

[Thomas Keller]

Am 12.01.11 01:00, schrieb Stephen Leake:
 Stephen Leake stephen_le...@stephe-leake.org writes:
 
 Thomas Keller m...@thomaskeller.biz writes:

 (Review the
 complete chapter 5 

 in monotone.texi

 done.
 
 Sigh, not it's not; only done thru 5.8 Key and Cert. it's late, and I'm
 going to bed now :).

Many, many thanks for your work so far!

Thomas.

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



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

Re: [Monotone-devel] mingw-instructions

[Thomas Keller]

Am 09.01.11 08:07, schrieb Richard Levitte:
 In message 82fwt37wtx@stephe-leake.org on Sat, 08 Jan 2011 19:19:22 
 -0500, Stephen Leake stephen_le...@stephe-leake.org said:
 
 stephen_leake Thomas Keller m...@thomaskeller.biz writes:
 stephen_leake  Finally I'm still unsure if we want to keep all these 
 install files in
 stephen_leake  the main directory or under doc/ or install/ or whatever.
 stephen_leake 
 stephen_leake Every package I've seen keeps all the INSTALL variants 
 together, in the
 stephen_leake top source directory; developers will expect to find them 
 there. Someone
 stephen_leake else here (Richard?) said the same thing.
 
 Yup, and I'll repeat it if needed ;-)

Okok, beats me - I'll leave them there :)

Thomas.

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



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

Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?

[Thomas Keller]

Am 08.01.11 08:30, schrieb Richard Levitte:
 In message 4d27b530.1080...@thomaskeller.biz on Sat, 08 Jan 2011 01:52:00 
 +0100, Thomas Keller m...@thomaskeller.biz said:
 
 me I'm working on issue 102 and to make this work properly I want to
 me create the diff output and return it instead of just printing it
 me to stdout directly. Problem is that the external diff hook calls
 me execute(diff, -u, ...) and I wonder if I should go through the
 me hassle and use spawn_redirected to catch and return the output
 me from there.
 
 I'm not sure what you're about to do...  it does sound like you want
 to create the whole diff in memory and output it when it's complete.

Yes, this was my intention. See
https://code.monotone.ca/p/monotone/issues/102/#ic315.

 In my opinion, that would be a bad idea (think huge diffs), and I'm
 not quite sure how that would fix the sorting order, which is the
 actual issue here.  Maybe I misunderstand what you're thinking of
 doing...

Well, my plan was to use the parallel node iterator to produce a diff
for all changed nodes and save the results to a multimap. Then I'd
iterate over this multimap and output the actual diff.

Thomas.

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





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

Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?

[Thomas Keller]

Am 08.01.11 14:54, schrieb CooSoft Support:
 Works + spanner spring to mind with my reply :-)
 
 Personally I couldn't care less that the au diff command doesn't have
 the --external option and I have never thought it inconsistent as one
 would only use it via some other tool like mtn-browse and if you wanted
 to use say kompare or kdiff3 then it is easy enough for something like
 mtn-browse to do that by fetching the files and doing it manually
 (mtn-browse actually does that).
 
 However on the ordinary mtn diff command I do have --external set up to
 use kompare and that can prove very useful when comparing complex
 unchecked in changes made inside a workspace. Easily got round with a
 script though, automating what Stephen suggested, so certainly not `a
 must have'.
 
 But I must admit I don't see the connection between the question and the
 diff sort order. Wouldn't diff be called per file so isn't it just the
 file order that needs sorting first? Also how does removing it make
 things faster?

I don't say its impossible to do, but it would require quite a lot more
code shuffling. If you look at the actual implementation in
cmd_diff_log.cc, around line 120, you see that we have to keep quite a
lot of state during a potential first round in order to sort things
before we go on with the second round which calculates and outputs the
actual diff.

In the end I'm just up for fixing this one bug, issue 102, so if you
think there is an easier / better way to do it, be my guest :)

Thomas.

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



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

Re: [Monotone-devel] mingw-instructions

[Thomas Keller]

Am 08.01.11 12:54, schrieb Stephen Leake:
 http://wiki.monotone.ca/RoadMap/  has an entry:
 
 Split INSTALL by platform and update it | n/a | 
 `net.venge.monotone{,.mingw-instructions}` | started |
 
 However, the mingw-instructions branch is more about upgrading to a
 newer version of the MinGW tools; splitting INSTALL is already done, on
 the main branch.

Right, only a few minor things are missing:

1) we should append a proper extension to that file and name it proper,
for example *.txt
2) we might think about converting it to DOS line endings, just to make
it look proper in the still-default text editor notepad

Finally I'm still unsure if we want to keep all these install files in
the main directory or under doc/ or install/ or whatever.

 I suggest we change this line to 'upgrade to newer MinGW tools'.

Feel free to do that.

 Note that main/INSTALL_windows_native says:
 
 The versions given here were used to build the current release of
 monontone.
 
 mingw-instructions changes that to:
 
 The versions given here may not be exactly the same versions as used
 to build the current release of monontone.
 
 Do we want to establish a policy of 'official mingw versions for mtn
 releases?
 
 If so, I suggest we move 'upgrade to new MinGW' to after 1.0, since
 there is lots of other work to do (ie, I'd rather not spend time trying
 the new MinGW stuff).
 
 Having an official MinGW version list is useful in the case of
 MinGW-version dependent bugs. This has happened in the past, with
 internationalization.
 
 If we don't care about official versions of MinGW tools (which would be
 difficult to enforce), then it doesn't really matter whether this is in
 1.0 or not.

I'm not into mingw and cannot say much about that, but in general we
have the same problems on other platforms as well, i.e. a new version of
a distro comes out and our Debian or Fedora instructions are
outdated because some package name or dependency changed. And I don't
think we actually want to support _every_ version of _every_ distro
where monotone can eventually be built on.
What we can see here is also that installation instructions are never
really complete nor 100% perfectly working, so a general disclaimer like
the one you stated above might be the way to go (or even something more
general like we tested this with release so-and-so last time,
everything might have changed in the meantime).

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



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

Re: [Monotone-devel] use case for :memory: database?

[Thomas Keller]

Am 08.01.11 17:29, schrieb Stephen Leake:
 I'm adding a description of the global options to monotone.texi.
 
 What is the use case for :memory: database?

One is for example that it gives you a throw-away database for remote
automate actions: If you (as a client) connect to a remote server from
which you query data, netsync requires some server identification
chatter, but since you do not actually need a local database, au remote
and au remote_stdio do fallback to :memory: by default and forget the
server key after the connection has been closed.

There might be other use cases for throw-away databases as well, but I
don't remember any thats not of academic nature...

Thomas.

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



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

Re: [Monotone-devel] The everlasting release

[Thomas Keller]

Am 08.01.11 16:25, schrieb Stephen Leake:
 Thomas Keller m...@thomaskeller.biz writes:
 
 Most of the work went into the
 wiki, especially nice here is the wiser use of tags and the new
 role-specific index pages. Not everything is ready there though, so lets
 concentrate on the most important / most viewed pages here [1] next and
 leave the rest as a later excercise.

 [1] http://picpaste.com/most-viewed-wiki-pages-lKgdkkAL.png
 
 I'm working my way down that list.
 
 I skipped Projects Using Monotone; it's clearly an old snapshot, and I
 don't want to spend the time to update it. I think it's still useful.

From time to time people update this with newer stats, but actually we
ourselves don't know much of our users beside what they like to share
with us, so we cannot for sure bring this page up-to-date without that
our users step in and do it themselves.

 For Branches; I assume that's the total viewing time for all pages in
 the Branches directory?

Correct.

 What is the policy on deleting things from Branches? It seems like we
 could delete anything that landed more than one release back.

An alternative would be to tag these branch pages somehow nicely so that
only new and processing are accumulated and the done items wander
on some branch archive page. Maybe Richard or Lapo can help out with
some ikiwiki knowledge here about proper tagging.

Thomas.

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



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

[Monotone-devel] Transifex

[Thomas Keller]

Hi!

I created a transifex account a couple of months ago, but we couldn't
use it that much because transifex was VCS-centric and had no monotone
plugin back in the day.

They seemed to have beefed up their software last November though and
work rather file / resource centric now, so I took the chance and
uploaded all of the po files from the current version:

http://www.transifex.net/projects/p/monotone/resource/monotonepot/

Transifex now seems to provide a couple of services around this, namely
cloning existing translations, online-editing them, re-downloading them
and so on, which could be useful for people who only occasionally want
to look over a translation and provide fixes. I'll also further play
around with it and configure it to fetch updated resources automatically
from HTTP, so the stats and status is updated there.

Stay tuned,
Thomas.

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



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

[Monotone-devel] Quick poll: Does anybody actually still use diff with --external?

[Thomas Keller]

I'm working on issue 102 and to make this work properly I want to create
the diff output and return it instead of just printing it to stdout
directly. Problem is that the external diff hook calls execute(diff,
-u, ...) and I wonder if I should go through the hassle and use
spawn_redirected to catch and return the output from there.

One of the main problems is that we have no spawn_redirected
implementation on win32 yet, so --external will fail there. On the other
hand I wonder how many people actually use --external nowadays, given
the fact that we haven't heard many complaints that the internal diff
algorithm produces wrong results compared to diff(1).

Another problem with --external is that its currently also only
available in diff, but not automate content_diff, for much of the same
reason that the diff command plainly prints out the created diff, so
there is this minor incompleteness between both commands.

So, is this a must-have feature or do you think this could be removed
(and simplify and fasten the code at the same time)?

Thomas.

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



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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Thomas Keller]

Am 04.01.2011 05:48, schrieb Zack Weinberg:
 On Mon, Jan 3, 2011 at 11:36 AM, Richard Levitte rich...@levitte.org wrote:
 In message aanlkti=buu5ovw3xwzkwg9-xamdmjn8xc1i5uaxvv...@mail.gmail.com on 
 Mon, 3 Jan 2011 10:28:56 -0800, Zack Weinberg za...@panix.com said:

 zackw Is libssl-dev installed?  Does the botan-dev package (whatever it's
 zackw actually named) depend on libssl-dev, as it seems it needs to?

 Why should libbotan1.7-dev need to depend on libssl-dev?
 
 It's botan-config that adds -lcrypto to the link line, so it's
 libbotan1.7-dev's responsibility to ensure that the bare
 libcrypto.so symlink exists, which would be accomplished by
 depending on libssl-dev.
 
 (I'm a little surprised this is the case, I thought botan had its own
 crypto primitives and that the weird libssl license precluded its
 using ssl's)

I had similar issues with the botan package on MacPorts and openSUSE a
while ago and reported that upstream. IIRC the reason why there is a
(optional) dependency to libssl at all is because botan can use libssl's
or its own implementation of various hash functions such as sha1 and
choose whatever is the fastest for the particular used hardware and setup.

Thomas.


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




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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Thomas Keller]

Am 03.01.2011 16:56, schrieb Hendrik Boom:
 /usr/bin/ld: cannot find -lcrypto

This seems to be the problematic line - problem seems to be that
libbotan(-whatever) on Debian doesn't pull the libcrypto package. We
could easily add this to our list of libs, though.

Thomas.

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




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

Re: [Monotone-devel] The everlasting release

[Thomas Keller]

Am 01.01.11 22:36, schrieb Richard Levitte:
 In message 8239pccp0l@stephe-leake.org on Sat, 01 Jan 2011 16:06:34 
 -0500, Stephen Leake stephen_le...@stephe-leake.org said:
 stephen_leake base.hh is in ../monotone.source-tree-cleanup/src.
 
 For any file in ../monotone.source-tree-cleanup/src/win32/, base.hh is
 in .. .
 
 Have a look at, for example, unix/fs.cc.  It includes ../base.hh.
 That's the kind of thing that needs to be done.  Why it hasn't been
 done in src/win32/get_system_flavour.cc but has in src/win32/fs.cc, I
 cannot say.  I'll assume that someone simply missed it...

That one was me, I simply missed it. Thanks for fixing it.

Thomas.

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



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

[Monotone-devel] contrib/ handling

[Thomas Keller]

Hi!

I've talked with Richard tonight on IRC how we want to handle
contributions in monotone's source distribution in the future. Some raw
notes here:

1) We agreed that we only want to ship at least minimal tested stuff in
   our tarball; most of the lua functionality (custom commands, hook
   scripts) should be faily easy to test with the right tools available,
   other things like shell completion scripts should be at least minimal
   tested (in case the shell binary exists a test would at least assure
   that this binary can load the completion script at all)

2) Point 1) means that we will no longer plainly ship everything under
   contrib/ and examples/, but only selected and tested stuff. contrib/
   will remain in the source tree, but will be removed from EXTRA_DIST.
   Tested (moved) stuff will be transferred into a new extra/ dir, which
   will have several sub directories beneath it (one for hook scripts,
   one for commands, one for shell completions scripts, one for the
   rest); naming for the subdirs is not yet decided.

3) We'll put the tests for anything in extra/ in a separate test suite,
   for two reasons: One the one hand we don't like to mix core from
   extra tests and on the other hand we might want to make our make
   check target then more selective, i.e. do not run extra tests by
   default since this target is often used during automated builds
   in distributions, but only activate this on selected tester machines
   where we know most (all!) of the needed test tools are available
   (for example - all shell binaries are installed and available)

There is no ETA on all this, but we want to finish that before 1.0 (see
it as an extended version of the RoadMap entry Cleanup and document
stuff in contrib/).

Thomas.

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



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

[Monotone-devel] The everlasting release

[Thomas Keller]

Hi!

As you might have noticed the immediate release of 1.0 this year becomes
somewhat unrealistic when you look at the amount of work we still like
to get done before we all have this warm and fuzzy feeling to have
something sound overall. As a consequence I retargeted 1.0 for early
2011 now and I hope we can meet this better.


Right now the bug tracker is filling with some minor and some not so
minor nuisances of 0.99.1 and earlier. I added a new Milestone:1.0 tag
to some of them [0] to gather a quick overview. Feel free to tag more
(reproducable) issues with this label which you want to see fixed before
1.0 is finally ready.

A bit more than a week ago we held off our small docathon, thanks again
to Richard who did the management for me. Most of the work went into the
wiki, especially nice here is the wiser use of tags and the new
role-specific index pages. Not everything is ready there though, so lets
concentrate on the most important / most viewed pages here [1] next and
leave the rest as a later excercise.
The README and manual cleanup have been two other topics for the
docathon. Stephe worked on the readme files, but I am currently not
quite sure what his status is here. Tim also committed some updates for
the mingw32 installation instructions in a separate branch
(nvm.mingw-instructions), again, I'm not sure what the status is here.
The mark-merge discussion from the manual was moved to the wiki by
Richard, but there is more than that still on the todo. (Review the
complete chapter 5 and 7 for example, the things about our apparent
IDNA support read dubious, there is a hook mentioned
display_decoded_idna which is nowhere else referenced any longer, the
hash integrity discussion might need an update to accompany more recent
development, move the cvs phrasebook stuff into the wiki and add
accompanying sections for svn, git, hg...,  and finally I still think
the huge pcre pattern documentation is a bit overwhelming for the little
usage of patterns we have for the user actually.)

As a fall-out of the aforementioned docathon I started to clean up our
source tree a little and moved stuff around (work is kept in
nvm.source-tree-cleanup). Thanks again to Richard which helped me with
some automake issues here and there this slowly gets in a usable shape.
Whats missing is the documentation and more testing on other platforms
(Win32 most noticably) before this hits the trunk. In the meantime Tim
also worked quite hard on nvm.visualc, which we might also want to get a
little earlier into trunk for better testing. (Please see Tim's earlier
mail about details here.)

The RoadMap [2] contains two more entries which target the UI strings
and translations. No work was done in this area so far, and I have to
admit that I did nothing myself since the original team-up proposal
with the git / hg guys to streamline the German translations of all
three VCSes. Lets eat humble pie here and concentrate on sanitizing our
strings in the source at first and complete the existing translations
ourselves as far as we get. Everything else depends on external
resources which are rather unplannable and maybe even unavailable.

I'm a bit sick at the moment and try to motivate myself to continue my
work on guitone's libgraphviz implementation, which is another personal
matter. So don't wait for me to get started on something, just start.
I'll review whatever you do and provide responses to any upcoming questions.

Thanks for reading so far,
Thomas.

[0] https://code.monotone.ca/p/monotone/issues/label/399/open/
[1] http://picpaste.com/most-viewed-wiki-pages-lKgdkkAL.png
[2] http://wiki.monotone.ca/RoadMap/

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



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

Re: [Monotone-devel] question about monotone serve

[Thomas Keller]

Am 25.12.10 20:32, schrieb Hugo Cornelis:
 Hi all,
 
 
 I am trying to start a monotone server on port 4704, listening on all local
 network interfaces.  But monotone complains about the syntax of the bind
 command line argument.
 
 This is the command line I use:
 
 $ mtn --db /home/cornelis/neurospaces_project/MTN/rtxi.mtn serve
 --bind=:4704
 mtn: misuse: unable to parse host of URI ':4704'

This pops up because of a stupid workaround from me in
network/connection_info.cc:527 (setup_for_serve) - Aaron is right,
0.0.0.0:4691 should work in the meantime. Issue 119.

 PS: when the socket is still in TIME_WAIT I also got a 'bug in monotone'
 report:
 $ mtn --db /home/cornelis/neurospaces_project/MTN/rtxi.mtn serve
 --bind=localhost:4704
 mtn: fatal: std::runtime_error: network error: listen(2) error: Address
 already in use
 mtn: this is almost certainly a bug in monotone.
 mtn: please send this error message, the output of 'mtn version --full',
 mtn: and a description of what you were doing to monotone-de...@nongnu.org.
 mtn: wrote debugging log to
 /home/cornelis/neurospaces_project/developer/source/snapshots/0/_MTN/debug
 mtn: if reporting a bug, please include this file

I cannot reproduce that on OSX with 0.99.1 - it always exits cleanly
with mtn: network error: bind(2) error: Address already in use shortly
after I quit a client connection to a server and try to setup a new
server (netstat still tells me its in TIME_WAIT). Could you please paste
the debug file somewhere? Many thanks!

Thomas.

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



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

[Monotone-devel] Fwd: [IANA #409987] Re: Port Number Modification Template: 4691

[Thomas Keller]

Finally our requested port change (name changes from monotone to
mtn, I'll be set as contact) seems to go through - many thanks again
to Richard who managed to get together with the former contact Tomas Fasth!

Thomas.

 Original-Nachricht 
Betreff: [IANA #409987] Re:  Port Number Modification Template: 4691
Datum: Wed, 22 Dec 2010 20:02:01 +
Von: Pearl Liang via RT port-...@iana.org
Antwort an: port-...@iana.org
An: m...@thomaskeller.biz, to...@debian.org

Hello,

Thank you for your recent responses.  We have reviewed the request.
We can proceed with the requested changes since we have received
sufficient information.

We will notify the new contact when the processing is complete.

Thank you,

Pearl Liang
ICANN/IANA



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

Re: [Monotone-devel] migrate required in 1.0dev?

[Thomas Keller]

Am 20.12.10 12:24, schrieb Stephen Leake:
 mtn 1.0dev is telling me a migrate is needed relative to mtn 0.99.1, but
 I don't see an entry in NEWS for that.
 
 I guess it's this:
 
f94d3092bdb3a65bceb1acd654d3e3c3f7df2676
2010-11-28T18:17:39  Timothy Brownawell  tbrow...@prjek.net
  Better indexing for the revision_certs table, so that looking up the
  certs on a particular revision is faster (can pull everything from the
  index, without having to go look up in the table).
 
 I added a generic schema has changed NEWS entry; I'm not clear whether
 we need to explain why.

Thanks for noting that. The justification for this change can be read here:

http://article.gmane.org/gmane.comp.version-control.monotone.devel/18555

I accepted it because the rules on database migrations weren't set into
stone at that day and because the change was simple, yet noticable
enough for our users. Tim, Stephe, feel free to expand the short note in
NEWS with a small sentence what use cases should benefit from that
change the most (from what I remember ls branches and au branches should
be the most important ones).

Thomas.

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



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

Re: [Monotone-devel] IANA registration change declined

[Thomas Keller]

Am 15.12.2010 10:10, schrieb Richard Levitte:
 In message 4cf03f0b.3010...@thomaskeller.biz on Sat, 27 Nov 2010 00:13:15 
 +0100, Thomas Keller m...@thomaskeller.biz said:
 me Very cool, thanks for your initiative! I already got his email to IANA
 me in CC, now lets hope thats enough for the switch. Alternatively I have
 me to re-issue the request again.
 
 I haven't heard anything about this for a bit, and wonder how it's
 going.

IANA asked a few questions to Tomas Fasth (I was on CC), but he hasn't
responded to them yet (or at least not without putting me in CC).

I'll try to contact him again. Thanks for the reminder.

Thomas.

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




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