gmane.comp.version-control.monotone.devel

Re: Database recovery: `mtn load` into what?

Douglas Dickinson — 2012-05-23T00:15:45

Just answered my own question:

    mtn db --db ./new.mtn  load  < previous.sql-dump

will *create* new.mtn from scratch

I'll update the wiki.

Happy hacking,
./ddd

On Mon, May 21, 2012 at 7:44 PM, Douglas Dickinson <douglasdd< at >gmail.com> wrote:

_______________________________________________
Monotone-devel mailing list
Monotone-devel< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Database recovery: `mtn load` into what?

Douglas Dickinson — 2012-05-22T02:44:52

Docs for `mtn db load` are unclear to me.
    http://www.monotone.ca/docs/Database.html
says:

OK, fine, but how do you create a database without `mtn db init`?

Many thanks for your help!
./ddd


Background / context:  I'm trying to fix a database for which `mtn db
check` reports:


--
"Why, oh why, didn't I take the *blue* pill?"

Updated Issue 208 - ml_gobject.c: conflicting types for 'g_value_get_variant' (monotone)

2012-05-22T01:42:51

Hello,

The following issue has been updated:

208 - ml_gobject.c: conflicting types for 'g_value_get_variant'
Project: monotone
Status: New
Reported by: J Doe
URL: https://code.monotone.ca/p/monotone/issues/208/
Labels:
 Type:Defect
 Priority:Medium

Comments (last first):

# By J Doe, May 22, 2012:

Sorry; I went from Slackware to Debian... fresh reinstall.

# By Thomas Moschny, May 13, 2012:

(Reposting the comment, because email notifications were disabled)

Try to build using a system-wide installed lablgtk instead:

$ ./configure --without-local-lablgtk && make

You can test wether the system-wide installation is ok using:

$ ocamlfind query lablgtk2

# By Thomas Moschny, May 13, 2012:

Try to build using a system-wide installed lablgtk instead:

$ ./configure --without-local-lablgtk && make

You can test wether the system-wide installation is ok using:

$ ocamlfind query lablgtk2

# By J Doe, Apr 24, 2012:

Steps to reproduce the problem:
-------------------------------

1. ./configure && make #version monotone-viz-1.0.2
2. make fails with error attached

Expected result:
----------------
Make should run fine on my Slackware64

Actual results:
---------------
(outputs attached error)
ml_gobject.c:292:14: error: conflicting types for 'g_value_get_variant'

Output of `mtn version --full`:
-------------------------------
mtn not found because make failed

Attachments:
- ml_gobject_make_error.txt - 636 bytes
  https://code.monotone.ca/p/monotone/issues/view/attachment/46/ml_gobject_make_error.txt




--
Issue: https://code.monotone.ca/p/monotone/issues/208/

Re: Issue 209 - support drop/modified conflict(monotone)

Stephen Leake — 2012-05-14T00:56:00


I'd like to fix this for the release, unless it turns out to be too hard.

Issue 209 - support drop/modified conflict(monotone)

2012-05-14T00:37:52

Hello,

A new issue has been created:

209 - support drop/modified conflict
Project: monotone
Status: New
Reported by: Stephen Leake
Labels:
 Type:Incorrect Behavior
 Priority:Medium

Description:

Steps to reproduce the problem:
-------------------------------

1. create two heads, one with file_a modified, one with file_a dropped
2. merge

Expected result:
----------------
merge reports a drop/modified conflict

Actual results:
---------------
warning about modifications being lost due to drop

Output of `mtn version --full`:
-------------------------------
1.0

--
Issue: https://code.monotone.ca/p/monotone/issues/209/

Re: merge nvm.lua-5.2

Stephen Leake — 2012-05-14T00:33:32


Since there were none, I've propagated.

Updated Issue 202 - 'mtn conflicts resolve_first' error message w/o resolution (monotone)

2012-05-14T00:24:36

Hello,

The following issue has been updated:

202 - 'mtn conflicts resolve_first' error message w/o resolution
Project: monotone
Status: Fixed
Reported by: joe 23
URL: https://code.monotone.ca/p/monotone/issues/202/
Labels:
 Type:Defect
 Priority:Medium

Comments (last first):

# By Stephen Leake, May 14, 2012:

fixed in 384d89bf03cca6815b2df2580001d67378e41d26

 Status: Fixed

# By joe 23, Jan 22, 2012:

Steps to reproduce the problem:
-------------------------------

1. mtn conflicts store
2. mtn show_first
3. mtn resolve_first    # missing resolution

Expected result:
----------------
An error message, perhaps listing the possible resolutions, the same as the show_first output

Actual results:
---------------
mtn: fatal: std::out_of_range: src/cmd_conflicts.cc:366: index '0' = 0 overflowed vector 'args' with size 0
mtn: This is almost certainly a bug in monotone.


Output of `mtn version --full`:
-------------------------------

1.0.0



--
Issue: https://code.monotone.ca/p/monotone/issues/202/

Updated Issue 208 - ml_gobject.c: conflicting types for 'g_value_get_variant' (monotone)

2012-05-13T21:06:51

Hello,

The following issue has been updated:

208 - ml_gobject.c: conflicting types for 'g_value_get_variant'
Project: monotone
Status: New
Reported by: J Doe
URL: https://code.monotone.ca/p/monotone/issues/208/
Labels:
 Type:Defect
 Priority:Medium

Comments (last first):

# By Thomas Moschny, May 13, 2012:

(Reposting the comment, because email notifications were disabled)

Try to build using a system-wide installed lablgtk instead:

$ ./configure --without-local-lablgtk && make

You can test wether the system-wide installation is ok using:

$ ocamlfind query lablgtk2

# By Thomas Moschny, May 13, 2012:

Try to build using a system-wide installed lablgtk instead:

$ ./configure --without-local-lablgtk && make

You can test wether the system-wide installation is ok using:

$ ocamlfind query lablgtk2

# By J Doe, Apr 24, 2012:

Steps to reproduce the problem:
-------------------------------

1. ./configure && make #version monotone-viz-1.0.2
2. make fails with error attached

Expected result:
----------------
Make should run fine on my Slackware64

Actual results:
---------------
(outputs attached error)
ml_gobject.c:292:14: error: conflicting types for 'g_value_get_variant'

Output of `mtn version --full`:
-------------------------------
mtn not found because make failed

Attachments:
- ml_gobject_make_error.txt - 636 bytes
  https://code.monotone.ca/p/monotone/issues/view/attachment/46/ml_gobject_make_error.txt




--
Issue: https://code.monotone.ca/p/monotone/issues/208/

Re: can't update issues

Richard Levitte — 2012-05-13T10:20:10

In message <82zk9csy00.fsf< at >stephe-leake.org> on Sat, 12 May 2012 20:52:47 -0400, Stephen Leake <stephen_leake< at >stephe-leake.org> said:

stephen_leake> I've fixed issue 202, but I can't edit the issue via code.monotone.ca.
stephen_leake> 
stephen_leake> As soon as I start to edit in the 'comment' box, the page disappears,
stephen_leake> and leaves me with a "No issues were found" list. As if it had searched
stephen_leake> for something, and not found anything.

I got the tip to clear the browser cache from Thomas...  since then, I
don't have that issue any more.

Cheers,
Richard

can't update issues

Stephen Leake — 2012-05-13T00:52:47

I've fixed issue 202, but I can't edit the issue via code.monotone.ca.

As soon as I start to edit in the 'comment' box, the page disappears,
and leaves me with a "No issues were found" list. As if it had searched
for something, and not found anything.

Help!

merge nvm.lua-5.2

Stephen Leake — 2012-05-12T23:39:28

I have lua-5.2 installed in Mingw, and it's actually somewhat difficult
to install a different version (not like Debian :(). 

So are there any objections to merging nvm.lua-5.2?

Do we have a release manager?

Re: New indefero version deployed

Richard Levitte — 2012-05-11T09:47:30

In message <4FAAD7F3.6090205< at >thomaskeller.biz> on Wed, 09 May 2012 22:47:47 +0200, Thomas Keller <me< at >thomaskeller.biz> said:

me> 
me> Hi all!
me> 
me> I've deployed a new version of Indefero (1.3.2) and merged it with our
me> custom layout. Let me know if you find any hiccups (note though that you
me> should clear your browser cache before... :)
me> 
me> A list of notable changes since v1.2 (which is what we were previously
me> running) can be found here:
me> 
me>   <http://projects.ceondo.com/p/indefero/page/News/>
me> 
me> (The activity calculation is not enabled for our setup, btw...)

The jquery hotkeys plugin that's used in this new version doesn't work
right with Google Chrome on my laptop.  Basically, it seems like the
plugin isn't plugged in, and therefore, the last keydown binding is in
effect *for*any*key*I*happen*to*press*!  Doesn't make it easy to make
changes to any issue, I'll tell ya! ;-)

Could you please turn off those hotkeys?

Cheers,
Richard

New indefero version deployed

Thomas Keller — 2012-05-09T20:47:47

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.

Re: nvm.lua-5.2 failing on mingw

Ludovic Brenta — 2012-05-08T09:43:43

Yes but that came as a slight surprise and is causing a stir[1,2].

[1] http://lists.debian.org/debian-release/2012/05/msg00175.html
[2] http://lists.debian.org/debian-gcc/2012/05/msg00075.html


I built monotone 1.0-6 yesterday night with g++-4.7 and 
libbotan1.10-dev
with no problems.  All the tests passed.  I'll wait 3 days for 1.0-5 to
reach testing before I upload, though.

Re: nvm.lua-5.2 failing on mingw

Stephen Leake — 2012-05-08T08:15:04


Right, this failure is specific to MinGW; it has been there since extra
was introduced.


The failure appears to be in the test suite itself; it is not invoking
mtn properly. No one has had the time to investigate.

I don't use any of the tools tested in extra (on any platform), and
apparently no one has complained that they don't work on MinGW (either
no one else uses them, or they do work).


The test failure occurs on nvm as well, so no need to hold the merge on
that account.

Re: nvm.lua-5.2 failing on mingw

Stephen Leake — 2012-05-08T08:09:19


So the release plan for Debian is to have 4.7?

I guess mtn has been tested with unstable recently, so the C++ exception
bug appears to be specific to MinGW.

Re: nvm.lua-5.2 failing on mingw

Richard Levitte — 2012-05-07T11:52:10

In message <8262c8jk9h.fsf< at >stephe-leake.org> on Mon, 07 May 2012 12:36:10 +0100, Stephen Leake <stephen_leake< at >stephe-leake.org> said:

stephen_leake> Stephen Leake <stephen_leake< at >stephe-leake.org> writes:
stephen_leake> 
stephen_leake> > Completely reinstalling mingw, using an older installer that has g++
stephen_leake> > 4.5.2, fixed this particular problem (running 'make check' now).
stephen_leake> >
stephen_leake> > So apparently g++ 4.6.2 has problems with exceptions on Mingw. Cygwin is
stephen_leake> > still at 4.5.3; I don't think Debian is at 4.6 yet. So perhaps this is
stephen_leake> > not surprising.
stephen_leake> 
stephen_leake> 'make check' now completed.
stephen_leake> 
stephen_leake> tester and unit tests all pass.
stephen_leake> 
stephen_leake> func tests had one failure; netsync_key_hooks didn't get the expected
stephen_leake> return value from the server when sent SIGTERM. I think this is a known
stephen_leake> bug in MinGW, so we should skip that test.
stephen_leake> 
stephen_leake> All of the extra tests failed, as on the previous release. The failure
stephen_leake> is 'attempt to call global 'mtn_setup' (a nil value)', so there's
stephen_leake> something fundamental wrong in extra test driver.
stephen_leake> 
stephen_leake> In sum; as far as Cygwin and MinGW are concerned, nvm.lua-5.2 can be
stephen_leake> merged to main.

Wait, you're saying all of "extra" is failing?  I definitely don't get
that on my (Linux) box...

I'm also a bit surprised that we consider failures with the "extra"
part ok.

Other than that, I agree that nvm.lua-5.2 should be merged into nvm.

Re: nvm.lua-5.2 failing on mingw

Richard Levitte — 2012-05-07T11:49:00

In message <82bom0jm2s.fsf< at >stephe-leake.org> on Mon, 07 May 2012 11:56:59 +0100, Stephen Leake <stephen_leake< at >stephe-leake.org> said:

stephen_leake> So apparently g++ 4.6.2 has problems with exceptions on Mingw. Cygwin is
stephen_leake> still at 4.5.3; I don't think Debian is at 4.6 yet. So perhaps this is
stephen_leake> not surprising.

sid (Debian unstable) is at 4.6.3.  No issues there.

Re: nvm.lua-5.2 failing on mingw

Stephen Leake — 2012-05-07T11:36:10


'make check' now completed.

tester and unit tests all pass.

func tests had one failure; netsync_key_hooks didn't get the expected
return value from the server when sent SIGTERM. I think this is a known
bug in MinGW, so we should skip that test.

All of the extra tests failed, as on the previous release. The failure
is 'attempt to call global 'mtn_setup' (a nil value)', so there's
something fundamental wrong in extra test driver.

In sum; as far as Cygwin and MinGW are concerned, nvm.lua-5.2 can be
merged to main.

Re: nvm.lua-5.2 failing on mingw

Ludovic Brenta — 2012-05-07T11:32:08

Yes, Debian (unstable) is at 4.6 and even transitioning to 4.7 now.  
Debian
stable is 15 months old and at 4.4.

Re: nvm.lua-5.2 failing on mingw

Stephen Leake — 2012-05-07T10:56:59


Completely reinstalling mingw, using an older installer that has g++
4.5.2, fixed this particular problem (running 'make check' now).

So apparently g++ 4.6.2 has problems with exceptions on Mingw. Cygwin is
still at 4.5.3; I don't think Debian is at 4.6 yet. So perhaps this is
not surprising.