monotone on windows

[Hendrik Boom]

What does one do to use monotone on windows?

I'm on Linux and have been using monotone for ages.
I am considering a colaborationwith a windows user.
We'd like to be synchronising text files between us.

She is not a computer programmer; I'd probably have to set it up on her machine 
for her, and *I* don't know how Windows works these days.  The last time I used 
Windows as in the days of XP.

-- hendrik

possible bug

[Hendrik Boom]

Possible bug:

mtn: warning: expected file 'Melinda/src/delete', but it is a directory.
mtn: fatal: error: src/work.cc:1896: I(ident_existing_file(name, fid))
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 /home/hendrik/write/Melinda/_MTN/debug
mtn: if reporting a bug, please include this file

Version:

monotone 1.1 (base revision: 81fa9664405655b13bde971bddd802de25096073)
Running on  : Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 
(2018-05-07) x86_64
C++ compiler: GNU C++ version 5.4.0 20160609
C++ standard library: GNU libstdc++ version 20160609
Boost version   : 1_58
SQLite version  : 3.34.1 (compiled against 3.13.0)
Lua version : Lua 5.2
PCRE version: 8.39 2016-06-14 (compiled against 8.38)
Botan version   : 1.10.16 (compiled against 1.10.12)
Changes since base revision:
format_version "1"

new_manifest [3f49ef95c9afe8094b075119cad01839c44885e3]

old_revision [81fa9664405655b13bde971bddd802de25096073]

  Generated from data cached in the distribution;
  further changes may have been made.


I was trying to do a routing commit, after doing edits and moving a few 
obsolete files into the 'delete' directory.
Evidently I did something quite wrong, because monotone now thinks that delete 
is a file.

I *might* have done something like
mtn mv Makefile delete/
to move the obsolete file called Makefile into the 'delete' directory,
which I use as a kind of trash can, just in case.
But I really don't remember what I did any more.  I do remember making mistakes 
and haveing monotone quite reasonably call me out.

Until finally it thought it might have a bug.

I'll find a way to go on -- probably getting rid of the delete directory, 
creating a file called delete, and then mtn dropping it.

-- hendrik

Re: netsync with port forwarding -- SOLVED

[Hendrik Boom]

On Tue, Jun 08, 2021 at 10:16:18PM +0200, Michael Raskin wrote:
> >I believe I got it to work?  I found one more trick in the cofiguration 
> >menu.  Theres a firewall, which knows about proper redirection for a 
> >large number of protocols, but not netsync.
> >It turns out to have a garbage destination -- where to send all packets 
> >that it doesn't know what to do with.  This is presumably intended to ba 
> >a machine that cac collect statistics and check for ossible attacks.
> >
> >So I just designate my server as my garbage machine.
> 
> I believe you could also enable the incoming connections on the port in
> the firewall settings…

That's what I did originally on port 4691, and it did not work.
I suspect that netsync sets up an other port that the modem firewall
does not know about.  Is the port usage of netsync documented somewhere?

> on the other hand, if you want incoming 
> connections, it's on the server, so I guess you can call it a win…
> 
> >It will ignore any port that's not open, and I control that by what 
> >services I choose to provide.
> >
> >And if netsync uses the familiar trick of initiating a connexion on port 
> >4691 and than replying to say what port the rest of the comminication 
> >should take place on,
> >* it ould formerly get lost because redirection treats it as a attack,
> >* But now it's sent to the garbage machine, which does know what to do 
> >with it.
> 
> Pretty sure it does not…

Because the garbage machine *is* the server, it does know what to do.
For anything but the ports it opens (which might be dynamically assigned 
for some protocols) it just drops incoming junk.

And for netsync, the process on the server opening the right ports is 
usher, which knows what to do with netsync.

> 
> >And I went to a coffee shop to check it's working.
> 
> Oh well, that's what matters

Yes.

-- hendrik

Re: netsync with port forwarding -- SOLVED

[Hendrik Boom]

On Sun, Jun 06, 2021 at 08:21:44PM +0200, Michael Raskin wrote:
> >> >Netsync relies on some underlying conventions on the use of TCP for a 
> >> >two-way connexion.  Is there some other protocol that shares these 
> >> >conventions?  If so I could tell the modem that this other protocol is 
> >> >now being used on port 4691.
> >> 
> >> I would frankly start with tcpdump on both sides while trying to connect
> >> from outside. Routers can break so many things it is not even funny…
> >
> >I know.  A port forwarding NAT is an intense kludge.
> 
> Static port forwarding doesn't need to be, however routers sometimes 
> have a ton of interesting modes that make things complicated, usually 
> not well named.
> 
> Also, it could be that the router port forwards only connections from
> outside, while the ISP by default blocks incoming traffic on unknown 
> ports. In the latter case there are two options: actually believing it
> is good for safety, and letting through the ports explicitly requested
> (if a person can explain what port is needed, this person can probably
> be made to clean up their PC if malware gets too annoying for the 
> network); or trying to make residential connections less attractive 
> compared to business connections (doesn't work well in the world of 
> cheap VPS, but…)
> 
> >There was once a publicly accessible site of monotone repositories 
> >called something like mtn-prjk.net -- a kind of github for monotone.  
> >That would have accomplished my desire.  Alas!  it exists no more.
> 
> mtn-host.prjek.net, yes…
> 
> >Does netsync support IPv6?
> >
> >If so there will still be the question of whether the public and the 
> >coffee ships do.)
> 
> In principle Monotone even has some code conditional on IPv6 being used.
> Among ISPs, both coverage and brokenness vary for IPv6…
> 

I believe I got it to work?  I found one more trick in the cofiguration 
menu.  Theres a firewall, which knows about proper redirection for a 
large number of protocols, but not netsync.
It turns out to have a garbage destination -- where to send all packets 
that it doesn't know what to do with.  This is presumably intended to ba 
a machine that cac collect statistics and check for ossible attacks.

So I just designate my server as my garbage machine.

It will ignore any port that's not open, and I control that by what 
services I choose to provide.

And if netsync uses the familiar trick of initiating a connexion on port 
4691 and than replying to say what port the rest of the comminication 
should take place on,
* it ould formerly get lost because redirection treats it as a attack,
* But now it's sent to the garbage machine, which does know what to do 
with it.

And I went to a coffee shop to check it's working.

-- hendrik

Re: netsync with port forwarding

[Hendrik Boom]

On Sun, Jun 06, 2021 at 05:03:21PM +0200, Michael Raskin wrote:
> >On Sun, Jun 06, 2021 at 10:51:21AM +0200, Michael Raskin wrote:
> >> >Or is here some other way of achieving the same result -- letting 
> >> >netsync work when I'm not at home?
> >> 
> >> As an «adapt to the modem» approach, I would consider forwarding SSH and
> >> either port forwarding netsync in SSH connection or directly using SSH
> >> repository address (which means netsync through standard input/output
> >> through SSH).
> >
> >Two approaches here.
> >
> >(1) persuade modem to do the right thing with port 4691.
> >I've already done that, but it didn't help.  Presumably because port
> >forwarding is more complicated that just rewriting packets.  It is also 
> >necessary to do some kind of connexion tracking so that replies to 
> >incoming conexions are properly treated.
> >
> >It's entirely possible that the incomming netsync connection is properly 
> >routed to usher, but that ushers' reply is not getting out through the 
> >modem.
> >
> >Netsync relies on some underlying conventions on the use of TCP for a 
> >two-way connexion.  Is there some other protocol that shares these 
> >conventions?  If so I could tell the modem that this other protocol is 
> >now being used on port 4691.
> 
> I would frankly start with tcpdump on both sides while trying to connect
> from outside. Routers can break so many things it is not even funny…

I know.  A port forwarding NAT is an intense kludge.

There was once a publicly accessible site of monotone repositories 
called something like mtn-prjk.net -- a kind of github for monotone.  
That would have accomplished my desire.  Alas!  it exists no more.

Does netsync support IPv6?

If so there will still be the question of whether the public and the 
coffee ships do.)

-- hendrik

> 
> >(2) use ssh.
> >
> >I guess that would involve the ssh: URI's instead of mtn" URI's
> >
> >But this is a solution that works for me only.
> >
> >I'd like these some of these repositories to be readable 
> >by the public.  Monotone itself has enough safeguards on a netsync 
> >connexion for this.  But even if I use a separate account for montone 
> >repositories, someone that can use ssh to access monotone can also 
> >use ssh directly and attack the repositories (by tricks like rm).
> >
> >Or is some kind of limiter possible with ssh usage?
> 
> On the one hand it is, on the other one needs to be quite careful 
> setting it up to not leave a hole.

Maybe an account whose shell is usher?  Or something that knows how to 
usher?

-- hendrik

Re: netsync with port forwarding

[Hendrik Boom]

On Sun, Jun 06, 2021 at 10:51:21AM +0200, Michael Raskin wrote:
> >Or is here some other way of achieving the same result -- letting 
> >netsync work when I'm not at home?
> 
> As an «adapt to the modem» approach, I would consider forwarding SSH and
> either port forwarding netsync in SSH connection or directly using SSH
> repository address (which means netsync through standard input/output
> through SSH).

Two approaches here.

(1) persuade modem to do the right thing with port 4691.
I've already done that, but it didn't help.  Presumably because port
forwarding is more complicated that just rewriting packets.  It is also 
necessary to do some kind of connexion tracking so that replies to 
incoming conexions are properly treated.

It's entirely possible that the incomming netsync connection is properly 
routed to usher, but that ushers' reply is not getting out through the 
modem.

Netsync relies on some underlying conventions on the use of TCP for a 
two-way connexion.  Is there some other protocol that shares these 
conventions?  If so I could tell the modem that this other protocol is 
now being used on port 4691.

(2) use ssh.

I guess that would involve the ssh: URI's instead of mtn" URI's

But this is a solution that works for me only.

I'd like these some of these repositories to be readable 
by the public.  Monotone itself has enough safeguards on a netsync 
connexion for this.  But even if I use a separate account for montone 
repositories, someone that can use ssh to access monotone can also 
use ssh directly and attack the repositories (by tricks like rm).

Or is some kind of limiter possible with ssh usage?

-- hendrik

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

[Hendrik Boom]

On Sun, Jun 06, 2021 at 02:18:12PM +0100, CooSoft Support wrote:
> In my experience the merging in mtn presents the developer with far fewer
> conflicts to resolve. Plus you can merge multiple branches in one go by
> `baptising' those dev branches into the target developer/integration branch.

How do you do this?

> So it doesn't stand out at first, you just notice after a while that you
> have a lot less work than you'd expect with other SCMs.
> 
> As for git. Well one of the reasons that mtn is very good at merging, apart
> from any algorithm that is used to do it, is that it relies on the fact that
> you have a complete history and that any branch being merged must have
> branched off at some point from the branch that it is being merged back
> into. Otherwise you have to do a manual merge. Git doesn't place that `same
> origin branch' restriction on you.

There are occasional times I'd like that 'same origin branch' lifted.
Mostly when I discover ancient pre-monotone source code in some archive 
and would like to integrate it in to monotone's history.

> 
> Others on this mailing list may have a more in depth answer for you though.
> These are just my observations.

I seem to remember reading about restrictions in git on having to merge 
only only between very recently forked branches, and having to do 
rebasing to get around this.  I no longer remember the details. 

> On 06/06/2021 13:49, Hugo Cornelis wrote:
> > 
> > I have used monotone for a few years and was fine with it.
> > 
> > I used to hear a lot and still hear now and then that the approach to
> > merging in monotone is / was superior to the approach taken in git.  It
> > is something I have never understood.  My experience with merges in
> > monotone is actually quite limited (compared to experience with merges
> > with git).
> > 
> > How do they compare wrt merges?  What is so fundamentally different
> > between them?  And why makes this difference such a profound impact to
> > the developer experience?
> > 
> > Just wondering.
> > 
> > Would it be possible to integrate monotone-like merges into git?

Would it be possible to integrate git repositories into monotone 
repositories?  At the moment, traffic between monotone and git is 
one-way.

-- hendrik

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

[Hendrik Boom]

On Sun, Jun 06, 2021 at 12:53:11AM -0400, grarpamp wrote:
> As people noted in last months / years... the worlds OS, apps,
> developers, and tech oriented operating system / repo / code / porters
> eyeballs users and interactors have more or less moved en masse
> to git, primarily on github, often augmented by running
> their own git copies in house if they are a large project.
> 
> It's unlikely under what is now an ecosystem settled
> into git, that any new talent or otherwise will bother
> trying to use monotone or any other repo to fetch
> patch hack commit etc on anyones code, regardless
> of whether that code is an OS, a repo, or an app.
> It's the language problem, if you are one speaking Z,
> in a world where everyone else speaks only A,
> you will need to adapt to them.
> 
> If monotone wants to survive in a compileable state
> across OS, to maintain an example presence that
> alternative repo embodiments are available that do run
> and can be studied and tried out, it needs at minimum...
> 
> a) A tarball release that compiles against the latest
> versions of all external libraries, and on the latest
> release of FreeBSD and Linux-Debian.
> 
> and
> 
> b) A github repo (and ticket system) that is considered an
> "upstream" that can be interacted with and that will accept
> maintenance patches from the OS and userspace.
> 
> and
> 
> c) Some public FYI blurb advert when doing those interactions,
> and in the topline of the toplevel README, that monotone is
> accepting new maintenance / dev people. No one lives or
> maintains forever, thus wise continually seek new eyballs and
> people in wherever the new places are.

I might be willing to step up here, but I'm not a youngster that
will carry maintenance into the far future.  I'm 74.

-- hendrik

> 
> Otherwise monotone dies.
> 
> If there are compilation and bug patches out there waiting to
> be applied, and tarballs with them needing cut, then someone
> or some group throwing a monotone continuance project up on
> github and working those things there is probably not a bad idea.
> 

There used to be a very usable publicly accessible site that kept
people's monotone databases online.  I used it to back up my own 
development repositories.

-- hendrik

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

[Hendrik Boom]

On Sat, Jun 05, 2021 at 05:51:38PM +0200, Michael Raskin wrote:
> >Is anything being done about this?
> >Is the current botan so incompatible that it's hopeless to adapt?
> >
> >Or is monotone development and maintenance truly dead and I need to 
> >abandon ship and take what data I ca with me?
> 
> 1. You can easily check out a branch that actually works with botan2.
> I package it for Nixpkgs and it seems to work just fine. Unfortunately
> from bootstrapping point of view, you need some monotone to check out
> botan2-compatible monotone (for packaging I exported the branch to 
> GitHub)

Very interesting.  So it looks like making a proper devuan package for 
monotone would require taking the old source deb, replacing the code 
with your code, and updating the various dependencies in the old 
manifest to new ones.

Even without understanding much about debian packaging, that sounds 
feasible.

Where do I find the relevant monotone repositories.  (I very much want 
to preserve history while doing this.)

Do the repositories also contain the code normally used to create deb 
packages?  I am no very familiar with the existing monotone code 
infrastructure, nor with the processes required to submit an update to a 
dropped Debian package.

And what kind of test procedures are there for vetting a monotone 
release?

> 
> 2. I would also appreciate an official release including these changes.

So would I.  I might have some time to work on it once I have the 
required data and permissions.

(And it would help if I got monotone to work through my modem's port 
rerouting, but that's another thread on this mailing list)

-- hendrik

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

[Hendrik Boom]

On Sat, Jun 05, 2021 at 08:54:25AM -0700, Stephen Leake wrote:
> Hendrik Boom  writes:
> 
> > Or is monotone development and maintenance truly dead and I need to 
> > abandon ship and take what data I ca with me?
> 
> Just for reference, I gave up on monotone, and exported to git.

I stopped liking git when I learned about its limitations on merging and 
the need for rebasing. 

Of course I never really liked git in the first place.

monotone got merging branches right.

-- hendrik
 
> 
> -- 
> -- Stephe

netsync with port forwarding

[Hendrik Boom]

I've been using montone for years, and circumstances have forced me to move my 
server behind a Network Address Translation VDSL modem, setting up port 
forwarding to make it accessible to the world.

I use usher.

It's not working.

I have a VDSL modem that is supposed to do network address translation and 
port forwarding.

The VDSL modem is configured to map port 4691 of public IP number 
69.165.134.134 to port 4691 of local IP number 192.168.1.19

Mind you, the configuration menu on that modem has a huge list of 
programs it might be called on to do NAT translation for (includeing 
things like HTML, SMTP, and a lot of games), but monotone's netsync is 
no on the list, so I had to specify the IP number explicitly.

The port forwarding for http, smtp, and ssh work properly.

(1) laptop at home, connected within LAN, so no port forwarding is needed.

mtn sync mtn://192.168.1.19:4691/rackettown

Works flawlessly.  Also works without the ':4691' (or course)

(2) laptop at home, connection to the public IP address of mmy LAN

mtn  mtn sync mtn://69.165.131.134:4691/rackettown

fails:
mtn: warning: no branch pattern found in URI, will try to use suitable 
database defaults if available
mtn: connecting to 'mtn://69.165.131.134:4691/rackettown'
mtn:   include pattern  'com.pooq.hendrik.free.fun.rackettown*'
mtn:   exclude pattern  ''
mtn: network error: failed to connect: Connection refused

It doesn't help to use 'topoi.pooq.com' instead of 69.165.131.134 (not 
that I expected it to).

(3) laptop elsewhere (using a coffee shop's wifi, to be specific)

Completely unable to make a connection.

hendrik@midwinter:~/dv/fun/rackettown$ mtn sync
enter passphrase for key ID [hend...@midwinter.topoi.pooq.com] (a2c97968...): 
mtn: connecting to 'mtn://topoi.pooq.com/rackettown'
mtn:   include pattern  'com.pooq.hendrik.free.fun.rackettown*'
mtn:   exclude pattern  ''
mtn: network error: failed to connect: Connection timed out
hendrik@midwinter:~/dv/fun/rackettown$ 


Now ... is there something I should know about using port forwarding with the 
netsync protocol?  Is there something the modem/router needs to know about it?

Or is here some other way of achieving the same result -- letting 
netsync work when I'm not at home?

-- hendrik

Is monotone dead, or is there a path forward?

[Hendrik Boom]

On Mon, Feb 10, 2020 at 06:05:09PM +1100, Brian May wrote:
> Stephen Leake  writes:
> 
> > I've just installed a new Debian 10 VM, and upgraded to testing.
> >
> > 'aptitude search monotone' returns nothing!
> >
> > Is it finally time to stop using monotone?
> 
> monotone has been removed from Debian. As in both unstable and testing.
> It only exists in old distributions.
> 
> https://tracker.debian.org/pkg/monotone
> 
> First it was removed from testing:
> 
> https://tracker.debian.org/news/940070/monotone-removed-from-testing/
> 
> It was removed from testing because botan1.10 is no longer available in
> testing.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888089
> 
> Then it got removed from unstable:
> 
> https://tracker.debian.org/news/1089909/removed-11-9-from-unstable/
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943919
> 
> "Please remove monotone. It's dead upstream, last upload was over three
> years ago and it's removed from testing since 1.5 years."

Is there any hope for monotone?  It appears no longer to be in Debian stable.
I'm using Devuan beowulf, which is roughly combarable to the currently 
stable Debian 10.0=buster.

Debian buster does not have monotone.
Nor, as a result, does Devuan buster.
But I still have monotone available on my devian buster laptop, 
presumably because I had it long ago before I upgraded to the current 
stable system.

And it still seems to work.

If I were to have to re-install the OS, I would lose monotone, and hence 
the contents of my repositories.

Is anything being done about this?
Is the current botan so incompatible that it's hopeless to adapt?

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

-- hendrik

terminating branch development

[Hendrik Boom]

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

This might happen if development has reached an impasse,
or if it is completely successful and has been merged into the main project.

-- hendrik

aborting a merge

[Hendrik Boom]

Let's say I do a propagate from a main branch to a development branch.
I get dumped into emacs merge to sort things out.
Let's further say the emacs merge gets too hairy.  I need to do 
the merge more slowly with other tools, or perhaps start the merge 
over again, with more insight.

How do I get out of emacs merge mode without letting monotone 
think the merge has been completed?

I want to get back to the unmerged state so I can proceed with 
the complicated step-by-step merge tools exquisitely explained in 
the manual.

-- hendrik

Re: no monotone in Debian testing?

[Hendrik Boom]

On Mon, Feb 10, 2020 at 06:05:09PM +1100, Brian May wrote:
> Stephen Leake  writes:
> 
> > I've just installed a new Debian 10 VM, and upgraded to testing.
> >
> > 'aptitude search monotone' returns nothing!
> >
> > Is it finally time to stop using monotone?
> 
> monotone has been removed from Debian. As in both unstable and testing.
> It only exists in old distributions.
> 
> https://tracker.debian.org/pkg/monotone
> 
> First it was removed from testing:
> 
> https://tracker.debian.org/news/940070/monotone-removed-from-testing/
> 
> It was removed from testing because botan1.10 is no longer available in
> testing.

Is anything being done about it?

-- hendrik

> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888089
> 
> Then it got removed from unstable:
> 
> https://tracker.debian.org/news/1089909/removed-11-9-from-unstable/
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943919
> 
> "Please remove monotone. It's dead upstream, last upload was over three
> years ago and it's removed from testing since 1.5 years."
> -- 
> Brian May 
> 

Re: Fyi: this list, monotone-devel, just had it's subject [tag] and footer removed

[Hendrik Boom]

Does this policy violate antispam laws that require mailing list 
messages to contain instructions how to be taken off the list? 

-- hendrik

On Thu, Oct 24, 2019 at 04:18:39PM -0400, sysad...@gnu.org wrote:
> The Free Software Foundation has changed the GNU Mailman settings on
> this list. The short version is that any subject prefix or message
> footer has been removed, allowing us to turn off DMARC from munging.
> Any list administrator for this list is free to change these settings
> back, instructions are below.
> 
> The change is to better deal with increased adoption of the DMARC email
> standard. The default Mailman settings were causing messages sent from
> users with strict DMARC policy domains like yahoo.com to be rejected
> when sent to list subscribers by Mailman. See the end of this email for
> a technical overview of DMARC and DKIM. There are two main ways to fix
> the issue by changing Mailman list settings.
> 
> The first option, and the preferable way for discussion lists, is what
> we call the "unmodified message fix." There are Mailman list settings
> which modify the messages by adding a subject prefix (e.g. [list-name])
> or a footer. Modifying the message breaks DKIM message signatures and
> thus DMARC, so we just turn those off. Many lists are already this way
> and there is no change for them. Instead of using the subject prefix to
> identify a list, subscribers should use the List-Id, To, and Cc headers.
> List footer information can also be be put in the welcome email to
> subscribers and the list information page by list administrators.
> 
> We changed the default for new lists to send unmodified messages, and
> are now updating existing discussion lists to the new default. We
> emailed all list administrators and moderators and Savannah group admins
> to allow them to opt in to the alternate fix before we made this
> change. However, not all lists had a valid administrator contact.
> 
> The second option is for lists which want or need to continue to modify
> the message, for example with subject prefix or footer settings. In this
> case we turn on a Mailman list setting called dmarc_moderation_action:
> "Munge From". With this, if a strict DMARC sender sends to the list, we
> alter the headers of that message like so:
> 
> A message sent to the list:
> 
> From: Anne Example Person 
> 
> Is modified by Mailman and sent to subscribers as:
> 
> From: Anne Example Person via Alist 
> Reply-To: Anne Example Person 
> 
> Without going into all of the details, here's a few points about why we
> concluded the unmodified message fix is better for discussion
> lists. Email clients don't all treat munged messages the same way as
> unmunged, and humans read these headers so it can confuse people,
> causing messages not to be sent to the expected recipients. GNU Mailman
> has an option to do "Munge From" always, but does not recommend using
> it[1]. While we're not bound by what others do, it's worth noting that
> other very large free software communities like Debian GNU/Linux have
> adopted the unmodified message fix[2]. The unmodified messages fix
> avoids breaking DKIM cryptographic signatures, which show the message
> was authorized by the signing domain and seems like a generally good
> security practice. Tools to manage patches, for example patchew, use the
> from field and are tripped up by from munging.
> 
> For any Mailman list administrator who wants to change or look over the
> relevant settings: The dmarc_moderation_action setting is under "Privacy
> Options" subsection "Sender Filters". The only options that should be
> selected are "Accept" or "Munge From", along with corresponding changes
> to the subject_prefix option under "General Options", and msg_footer is
> under "Non-digest options".
> 
> If no list administrators or moderators are around for this list, anyone
> should feel free to try to track them down or figure out who should
> become one and explain in detail by replying to sysad...@gnu.org. Please
> be patient, this process may take several weeks.
> 
> Please send any questions that should be public to mail...@gnu.org. For
> private ones, just reply to sysad...@gnu.org.
> 
> For the general announcement of these changes, please read
> https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
> and
> https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html
> 
> 
> A short DMARC technical overview:
> 
> DMARC policy is a DNS txt record at a _dmarc subdomain. For example:
> 
> $ host -t txt _dmarc.yahoo.com
> _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100;
> rua=mailto:address@hidden;;;
> 
> The only important thing there for our purpose is p=reject. p=reject
> means that conforming mail servers that receive mail with a from header
> of *@yahoo.com will reject that email unless it was either 1. sent from
> Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM
> signature[5] is a public 

Re: [Monotone-devel] Won't transfer on syncing.

[Hendrik Boom]

On Wed, Sep 04, 2019 at 12:32:04AM -0500, Tim Brownawell wrote:
> On Mon, 2019-09-02 at 17:19 -0400, Hendrik Boom wrote:
> > today, for no obvious reason, I get error messages when I try to
> > sync 
> > whereas yesterday I did not.
> > [...]
> > mtn: finding items to synchronize:
> > /usr/bin/mtn: operation canceled: Terminated
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > mtn: error: sqlite error: database is locked
> > 
> > Don't know why the operation was cancelled, but the database locked
> > messages
> > result from requesting sync repeatedly.  Yes, I wait a while between
> > syncs.
> > What could cause the database to remain locked for hours?
> 
> Is there another process with that file open? And if so, what's its
> parent process?

There wasn't that  knew of.  Of course there might have been some dead 
process that left the file locked when it died.

> 
> 
> 
> > On client:
> > 
> > hendrik@midwinter:~/dv/fun/rackettown$ mtn log --brief --last=10
> > o   3292757161a37e2ff2fe1cfe76c982c19690cf84 
> > hend...@midwinter.topoi.pooq.com
> > 
> [...]
> > On server, the oldest two of these branches are the same.  Server has
> > one 
> > newer one, and client has several (different) newer ones;
> > 
> > 
> > hendrik@april:~/dv/fun/rackettown$ mtn log --last=10 --brief 
> > o   0dcbeac502ab204eb0cb9ca92ff132698afa4635 hend...@topoi.pooq.com
> > 
> >01/09/19 07:48:50 PM com.pooq.hendrik.free.fun.rackettown
> [...]
> > Yet when I do mtn sync on the client, I get:
> > 
> > hendrik@midwinter:~/dv/fun/rackettown$ mtn sync
> > mtn: connecting to 'mtn://topoi.pooq.com/rackettown'
> > mtn:   include pattern  'com.pooq.hendrik.free.rackettown*'
> > mtn:   exclude pattern  ''
> > mtn: finding items to synchronize:
> > mtn: successful exchange with 'mtn://topoi.pooq.com/rackettown'
> > mtn:  bytes in | bytes out | revs in
> > mtn:   351 |   712 | 0/0
> > hendrik@midwinter:~/dv/fun/rackettown$
> > 
> > 
> > Nothing changes.
> 
> The branch name for the include pattern does not match the branch name
> on the revisions (the "fun" component is missing).

Of course that would do it!  I thought I had carefully checked all that.
Evidently not carefully enough.

Thank you.

I've always thought monotone runs flawlessly once it's set up properly.
But getting the setup right is hard.

-- hendrik

> 
> -- 
> Tim
> 

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

Re: [Monotone-devel] Won't transfer on syncing.

[Hendrik Boom]

today, for no obvious reason, I get error messages when I try to sync 
whereas yesterday I did not.

On the client, 

mtn: received warning from usher: Cannot fork server.
mtn: peer mtn://topoi.pooq.com/rackettown IO terminated connection in 
working state (error)
mtn: error: I/O failure while talking to peer 
'mtn://topoi.pooq.com/rackettown', disconnecting

And on the server,

 the usher log reports:

mtn: beginning service on 127.0.0.1 : 15014
mtn: accepted new client connection from 127.0.0.1 : 50444
mtn: allowed 'a2c97968e6b55baf0e06f14db3a9ab9631cf3e00' read permission for 
'com.pooq.hendrik.free.rackettown*' excluding ''
mtn: allowed 'a2c97968e6b55baf0e06f14db3a9ab9631cf3e00' write permission for 
'com.pooq.hendrik.free.rackettown*' excluding ''
mtn: finding items to synchronize:
/usr/bin/mtn: operation canceled: Terminated
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked
mtn: error: sqlite error: database is locked

Don't know why the operation was cancelled, but the database locked messages
result from requesting sync repeatedly.  Yes, I wait a while between syncs.
What could cause the database to remain locked for hours?

-- hendrik

On Sun, Sep 01, 2019 at 08:31:04PM -0400, Hendrik Boom wrote:
> I seem to have screwed up again.
> 
> I have a different recent revisions on the client and server, and the same
> old revisions, yet when I sync nothing gets transferred.
> 
> I know that syncing from the client reaches the same database the server 
> uses, because when, immediately after doing the sync on the client, I do 
> anything involving the data base on the server, I get tne message 
> mtn: error: sqlite error: database is locked
> 
> Details
> 
> On client:
> 
> hendrik@midwinter:~/dv/fun/rackettown$ mtn log --brief --last=10
> o   3292757161a37e2ff2fe1cfe76c982c19690cf84 hend...@midwinter.topoi.pooq.com
> |2019-09-01 07:58:15 PM com.pooq.hendrik.free.fun.rackettown
> o   ebe9e6745d1cec6e97a9c9ecf0e59217a88acdc5 hend...@midwinter.topoi.pooq.com
> |2019-09-01 07:56:06 PM com.pooq.hendrik.free.fun.rackettown
> o   d83df26a42248c3f01a76a17440eb40d2dd9f57f hend...@midwinter.topoi.pooq.com
> |2019-08-30 05:52:18 PM com.pooq.hendrik.free.fun.rackettown
> o   30e5d1503fe354720b2dc537a0be15dfa134ffb2 hend...@topoi.pooq.com
> |2019-08-30 05:25:50 PM com.pooq.hendrik.free.fun.rackettown
> o   d167bdae9a6bc967db9d2a7a203be5fcfe9bd3c9 hend...@topoi.pooq.com
>  2019-08-30 04:38:28 PM com.pooq.hendrik.free.fun.rackettown
> hendrik@midwinter:~/dv/fun/rackettown$ mtn log --brief --next=10
> o   3292757161a37e2ff2fe1cfe76c982c19690cf84 hend...@midwinter.topoi.pooq.com
>  2019-09-01 07:58:15 PM com.pooq.hendrik.free.fun.rackettown
> hendrik@midwinter:~/dv/fun/rackettown$ mtn status
> --
> Revision: 63c9e1dc9e49d3bea82fef7f16cb1a6d1f7ff9ec
> Parent:   3292757161a37e2ff2fe1cfe76c982c19690cf84
> Author:   hend...@midwinter.topoi.pooq.com
> Date: 2019-09-01 08:14:48 PM
> Branch:   com.pooq.hendrik.free.fun.rackettown
> 
> Changes against parent 3292757161a37e2ff2fe1cfe76c982c19690cf84
> 
> no changes
> 
> hendrik@midwinter:
> 
> 
> 
> On server, the oldest two of these branches are the same.  Server has one 
> newer one, and client has several (different) newer ones;
> 
> 
> hendrik@april:~/dv/fun/rackettown$ mtn log --last=10 --brief 
> o   0dcbeac502ab204eb0cb9ca92ff132698afa4635 hend...@topoi.pooq.com
> |01/09/19 07:48:50 PM com.pooq.hendrik.free.fun.rackettown
> o   30e5d1503fe354720b2dc537a0be15dfa134ffb2 hend...@topoi.pooq.com
> |30/08/19 05:25:50 PM com.pooq.hendrik.free.fun.rackettown
> o   d167bdae9a6bc967db9d2a7a203be5fcfe9bd3c9 hend...@topoi.pooq.com
>  30/08/19 04:38:28 PM com.pooq.hendrik.free.fun.rackettown
> hendrik@april:~/dv/fun/rackettown$ mtn status
> --
> Revision: 6de736803a5ba38d42baa11a3580c2c5f9ce6317
> Parent:   0dcbeac502ab204eb0cb9ca92ff132698afa4635
> Author:   hend...@topoi.pooq.com
> Date: 01/09/19 08:20:24 PM
> Branch:   com.pooq.hendrik.free.fun.rackettown
> 
> Changes against parent 0dcbeac502ab204eb0cb9ca92ff132698afa4635
> 
> no changes
> 
> hendrik@april:~/dv/fun/rackettown$
> 
> 
> Yet when I do mtn sync on the client, I get:
> 
> hendrik@midwinter:~/dv/fun/rackettown$ mtn sync
> mtn: connecting to 'mtn://topoi.pooq.com/rackettown'
> mtn:   include pattern  'com.pooq.

[Monotone-devel] Won't transfer on syncing.

[Hendrik Boom]

I seem to have screwed up again.

I have a different recent revisions on the client and server, and the same
old revisions, yet when I sync nothing gets transferred.

I know that syncing from the client reaches the same database the server 
uses, because when, immediately after doing the sync on the client, I do 
anything involving the data base on the server, I get tne message 
mtn: error: sqlite error: database is locked

Details

On client:

hendrik@midwinter:~/dv/fun/rackettown$ mtn log --brief --last=10
o   3292757161a37e2ff2fe1cfe76c982c19690cf84 hend...@midwinter.topoi.pooq.com
|2019-09-01 07:58:15 PM com.pooq.hendrik.free.fun.rackettown
o   ebe9e6745d1cec6e97a9c9ecf0e59217a88acdc5 hend...@midwinter.topoi.pooq.com
|2019-09-01 07:56:06 PM com.pooq.hendrik.free.fun.rackettown
o   d83df26a42248c3f01a76a17440eb40d2dd9f57f hend...@midwinter.topoi.pooq.com
|2019-08-30 05:52:18 PM com.pooq.hendrik.free.fun.rackettown
o   30e5d1503fe354720b2dc537a0be15dfa134ffb2 hend...@topoi.pooq.com
|2019-08-30 05:25:50 PM com.pooq.hendrik.free.fun.rackettown
o   d167bdae9a6bc967db9d2a7a203be5fcfe9bd3c9 hend...@topoi.pooq.com
 2019-08-30 04:38:28 PM com.pooq.hendrik.free.fun.rackettown
hendrik@midwinter:~/dv/fun/rackettown$ mtn log --brief --next=10
o   3292757161a37e2ff2fe1cfe76c982c19690cf84 hend...@midwinter.topoi.pooq.com
 2019-09-01 07:58:15 PM com.pooq.hendrik.free.fun.rackettown
hendrik@midwinter:~/dv/fun/rackettown$ mtn status
--
Revision: 63c9e1dc9e49d3bea82fef7f16cb1a6d1f7ff9ec
Parent:   3292757161a37e2ff2fe1cfe76c982c19690cf84
Author:   hend...@midwinter.topoi.pooq.com
Date: 2019-09-01 08:14:48 PM
Branch:   com.pooq.hendrik.free.fun.rackettown

Changes against parent 3292757161a37e2ff2fe1cfe76c982c19690cf84

no changes

hendrik@midwinter:



On server, the oldest two of these branches are the same.  Server has one 
newer one, and client has several (different) newer ones;


hendrik@april:~/dv/fun/rackettown$ mtn log --last=10 --brief 
o   0dcbeac502ab204eb0cb9ca92ff132698afa4635 hend...@topoi.pooq.com
|01/09/19 07:48:50 PM com.pooq.hendrik.free.fun.rackettown
o   30e5d1503fe354720b2dc537a0be15dfa134ffb2 hend...@topoi.pooq.com
|30/08/19 05:25:50 PM com.pooq.hendrik.free.fun.rackettown
o   d167bdae9a6bc967db9d2a7a203be5fcfe9bd3c9 hend...@topoi.pooq.com
 30/08/19 04:38:28 PM com.pooq.hendrik.free.fun.rackettown
hendrik@april:~/dv/fun/rackettown$ mtn status
--
Revision: 6de736803a5ba38d42baa11a3580c2c5f9ce6317
Parent:   0dcbeac502ab204eb0cb9ca92ff132698afa4635
Author:   hend...@topoi.pooq.com
Date: 01/09/19 08:20:24 PM
Branch:   com.pooq.hendrik.free.fun.rackettown

Changes against parent 0dcbeac502ab204eb0cb9ca92ff132698afa4635

no changes

hendrik@april:~/dv/fun/rackettown$


Yet when I do mtn sync on the client, I get:

hendrik@midwinter:~/dv/fun/rackettown$ mtn sync
mtn: connecting to 'mtn://topoi.pooq.com/rackettown'
mtn:   include pattern  'com.pooq.hendrik.free.rackettown*'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: successful exchange with 'mtn://topoi.pooq.com/rackettown'
mtn:  bytes in | bytes out | revs in
mtn:   351 |   712 | 0/0
hendrik@midwinter:~/dv/fun/rackettown$


Nothing changes.


In case those revisions are already transferred (doubtful) I tried a mtn 
merge:

On server:

hendrik@april:~/dv/fun/rackettown$ mtn merge
mtn: branch 'com.pooq.hendrik.free.fun.rackettown' is already merged
hendrik@april:~/dv/fun/rackettown$

and on client:

hendrik@midwinter:~/dv/fun/rackettown$ mtn merge
mtn: branch 'com.pooq.hendrik.free.fun.rackettown' is already merged
hendrik@midwinter:~/dv/fun/rackettown$ 


I am mystified.

-- hendrik


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

Re: [Monotone-devel] undoing commits

[Hendrik Boom]

On Mon, Aug 05, 2019 at 03:56:02AM -0700, J Decker wrote:
> I'm sure it's way late now... but isn't ist just `mtn revert` ?

Just checked the documentation:  mtn revert undoes changes made to the 
workspace.
It does not undo the most recent commit.  So this is not what I want.  I just 
want 
the branch cert removed.

-- hendrik


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

Re: [Monotone-devel] undoing commits

[Hendrik Boom]

On Mon, Aug 05, 2019 at 03:56:02AM -0700, J Decker wrote:
> I'm sure it's way late now...

No, it's not too late.  I'm plannint to actually do this stuff 
later today.

> but isn't ist just `mtn revert` ?

Might be.  Ill look it up now I know what word to look for.

Can you do mtn revert twice to do two uncommits (neither 
has ever been synced).

-- hendrik

> 
> On Mon, Aug 5, 2019 at 3:48 AM Ludovic Brenta 
> wrote:
> 
> > Le 2019-08-05 02:21, Hendrik Boom a écrit :
> > > But if were to remove the branch certs (using the first instruction),
> > > is there also a way to install branch certs for the new branch?
> >
> > mtn approve rev [--branch=branchname] [--[no-]update]
> >
> >  This command puts rev on the branch branchname (defaults to the
> > workspace branch).
> >
> >  This command is a synonym for mtn cert rev branch branchname.
> >
> > --
> > Ludovic Brenta.
> >
> > ___
> > Monotone-devel mailing list
> > Monotone-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/monotone-devel
> >

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


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

Re: [Monotone-devel] undoing commits

[Hendrik Boom]

On Mon, Aug 05, 2019 at 12:00:26AM +0200, Ludovic Brenta wrote:
> Le 2019-08-04 23:45, Hendrik Boom a écrit :
> > I committed two revisions on the main branch of development that should
> > have been made on a new branch. (just to be awkward, some of those
> > edits should have been made on the main branch and others not.  Each
> > revision is a mixed bag)
> > 
> > How can I recover?
> > 
> > Isn't there some way to remove recent commits as long as they haven't
> > sync'd to any other data base?
> > 
> > Because I checked the copy of the data base on the server, and they
> > don't
> > seem to have gotten there yet.
> > 
> > So maybe I can check out the recent committed revisions (elsewhere, as
> > backups), revert those commits, and then hand-edit the changes back
> > that should have been on the main branch, subsequently start a new
> > branch, and then and edit the new-branch changes back onto the new
> > branch.
> > 
> > Does this sound practical?  Anyone have a better idea?  Or an obvious
> > gotcha?
> > 
> > My alternative would seem to be more drastic: delete the local database
> > altogether, copy an old version of it from the server, and try to
> > recover from there.
> 
> I would use SQL commands to delete the branch certs on the two offending
> revisions.  This would prevent them from being synced to other databases.
> Of course, prior to doing that, revert any working trees to an ancestor
> revision.

Following up from your suggestion and trying to figure out how to use 
sql for this, I found two commands:

mtn local kill_certs selector certname [certval] 

and

mtn local kill_revision id 

This second one looks like what I was asking for.  I'd still have to 
back up the files in a few previous revisions so as to identify changes 
and apply them selectively (probably by hand) to the main and new 
branches.

But if were to remove the branch certs (using the first instruction),
is there also a way to install branch certs for the new branch?  This 
would seem to be the simple way to set up the new branch properly.
Of course I'd still have to go over the differences line by line to copy 
selected changes to the main branch.

Of course there's a way to install new branch certs, or at least the 
equivalent.  set up the new branch, then mtn propagate from the main to 
the new branches.  *Then remove certs from the wrong commits on the main 
branch.  Would be nice to have something more direct, that just attaches 
a sert, but this would work.  There would be fewer junk revisions left 
lying around.

-- hendrik


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

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

[Monotone-devel] undoing commits

[Hendrik Boom]

I committed two revisions on the main branch of development that should
have been made on a new branch. (just to be awkward, some of those 
edits should have been made on the main branch and others not.  Each 
revision is a mixed bag)

How can I recover?

Isn't there some way to remove recent commits as long as they haven't
sync'd to any other data base?

Because I checked the copy of the data base on the server, and they don't
seem to have gotten there yet.

So maybe I can check out the recent committed revisions (elsewhere, as 
backups), revert those commits, and then hand-edit the changes back 
that should have been on the main branch, subsequently start a new 
branch, and then and edit the new-branch changes back onto the new 
branch.

Does this sound practical?  Anyone have a better idea?  Or an obvious 
gotcha?

My alternative would seem to be more drastic: delete the local database 
altogether, copy an old version of it from the server, and try to 
recover from there.

-- hendrik

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

Re: [Monotone-devel] interoperating with git

[Hendrik Boom]

On Wed, Oct 24, 2018 at 10:00:31AM -0700, Stephen Leake wrote:
> Hendrik Boom  writes:
> 
> > Planning to use monotone together with git.  Monotone for day-to-day 
> > activity, because it's a system I understand and trust.  Git for posting 
> > working versions on github or gitlab or some such.
> >
> > The obvious way to do this is to have one workspace that is used with 
> > both git and monotone.  git will be tld to ignore _MTN; monotone will be 
> > told to ignore .git .
> 
> I've done this with monotone and bazaar. It works, but is somewhat
> tedious, since you end up doing every commit twice (possibly grouped
> into larger commits for git, but still similar amount of work). I have
> some support for this in the Emacs DVC frontend - avalable from the
> ada-france monotone repository (see
> http://www.nongnu.org/ada-mode/ada-france-access.html for contact info).
> 
> A better option with monotone and git is to export the monotone db to a
> git repository. I have not done this yet, but others have reported
> success. Search this mailing list archive.

That seems like a one-time activity, perhaps not what I want for an 
ongoing development.  Or is there something I need to know about that I 
don't? 

> 
> -- 
> -- Stephe

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

[Monotone-devel] interoperating with git

[Hendrik Boom]

Planning to use monotone together with git.  Monotone for day-to-day 
activity, because it's a system I understand and trust.  Git for posting 
working versions on github or gitlab or some such.

The obvious way to do this is to have one workspace that is used with 
both git and monotone.  git will be tld to ignore _MTN; monotone will be 
told to ignore .git .

And. of course, similar treatment with other control files, such as the 
one that tells monotone to ignore .git.

Does this seem like a reasonable approach?
Is there something I've overlooked?
Is there a better approach?
Is there some new feature I should be looking at instead?

-- hendrik

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

Re: [Monotone-devel] Trouble cloning

[Hendrik Boom]

On Fri, Jun 29, 2018 at 07:34:03AM +1000, Brian May wrote:
> Hendrik Boom  writes:
> 
> > mtn: misuse: branch 'com.pooq.hendrik.howto' is empty
> > ...
> > com.pooq.topoi.howto
> 
> The branch name you used on the client looks different to the branch
> name the server shows.

Thanks.  I should have seen that.

-- hendrik

> 
> s/hendrik/topoi/
> -- 
> Brian May 

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

[Monotone-devel] Solved. Sorry for the width of bandwidth (was: Trouble cloning

[Hendrik Boom]

Never mind!  I found the problem.  Misspelled branch name.
Ouch!  Why did it take me a whole day to figure this out.

-- hendrik

On Thu, Jun 28, 2018 at 05:17:19PM -0400, Hendrik Boom wrote:
> I seem to have a data base that I can sync with (from one client system) 
> but cannot clone (to another ckient system).  Is this worth preserving 
> to find out why monotone exhibits thie strange behaviour?  If so, I'll 
> try to keep it aroung for analysis.  If not, I'll just delete it.
> 
> -- hendrik
> 
> On Thu, Jun 28, 2018 at 08:03:23AM -0400, Hendrik Boom wrote:
> > I'm sorry to be asking basic usage questions again.
> > 
> > I have no trouble with the everyday use of monotone -- mind you, the 
> > everyday commands are add, drop, sync, and update and they are pretty 
> > simple once everything has been set up.
> > 
> > But I don't clone often.  I don't set up new databases often, and I 
> > regret to say that I still need to ask on this list every time I do it.  
> > I always seem to do something wrong.
> > 
> > Today it's cloning a database from a server to a new machine.
> > 
> > Is clone even the right way to do this?  I could perhaps fall back 
> > to the more specific nonamalgameted commands.
> > 
> > hendrik@midwinter:~$ mtn clone --db=~/.monotone/databases/howto.mtn --key 
> > hend...@midwinter.topoi.pooq.com 
> > mtn://topoi.pooq.com/howto?com.pooq.hendrik.howto 
> > --branch=com.pooq.hendrik.howto howto
> > mtn: connecting to 'mtn://topoi.pooq.com/howto'
> > mtn:   include pattern  'com.pooq.hendrik.howto'
> > mtn:   exclude pattern  ''
> > mtn: finding items to synchronize:
> > mtn: successful exchange with 'mtn://topoi.pooq.com/howto'
> > mtn:  bytes in | bytes out | certs in
> > mtn:   351 |   701 |  0/0
> > mtn: misuse: branch 'com.pooq.hendrik.howto' is empty
> > hendrik@midwinter:~$
> > 
> > and listing the branches agrees.
> > 
> > hendrik@midwinter:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
> > hendrik@midwinter:~$ 
> > 
> > The thing is, listing the branches on the server does *not* agree:
> > 
> > hendrik@april:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
> > com.pooq.topoi.howto
> > hendrik@april:~$ 
> > 
> > (yes, the computer identifying itself as april in indeed also topoi.  
> > That's not the problem)
> > 
> > Somehow I've missed out on doing something.  I'm hoping other eyes will 
> > see what I don't.
> > 
> > Here's are the relevant usher stanzas I use on the server
> > 
> > userpass"hendrik" "notmypassword"
> > monotone"/usr/bin/mtn" "-k" "hend...@topoi.pooq.com"
> > listenaddr  "0.0.0.0:4691"
> > adminaddr   "127.0.0.3:12345"
> > logdir  "/farhome/hendrik/monotone/usher-log/"
> > 
> > server  "howto"
> > host"0.0.0.0"
> > pattern "com.pooq.topoi.howto"
> > local   "-d" "/farhome/hendrik/.monotone/databases/howto.mtn"
> > 
> > -- hendrik
> > 
> > 
> > ___
> > Monotone-devel mailing list
> > Monotone-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/monotone-devel
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

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

Re: [Monotone-devel] Trouble cloning

[Hendrik Boom]

I seem to have a data base that I can sync with (from one client system) 
but cannot clone (to another ckient system).  Is this worth preserving 
to find out why monotone exhibits thie strange behaviour?  If so, I'll 
try to keep it aroung for analysis.  If not, I'll just delete it.

-- hendrik

On Thu, Jun 28, 2018 at 08:03:23AM -0400, Hendrik Boom wrote:
> I'm sorry to be asking basic usage questions again.
> 
> I have no trouble with the everyday use of monotone -- mind you, the 
> everyday commands are add, drop, sync, and update and they are pretty 
> simple once everything has been set up.
> 
> But I don't clone often.  I don't set up new databases often, and I 
> regret to say that I still need to ask on this list every time I do it.  
> I always seem to do something wrong.
> 
> Today it's cloning a database from a server to a new machine.
> 
> Is clone even the right way to do this?  I could perhaps fall back 
> to the more specific nonamalgameted commands.
> 
> hendrik@midwinter:~$ mtn clone --db=~/.monotone/databases/howto.mtn --key 
> hend...@midwinter.topoi.pooq.com 
> mtn://topoi.pooq.com/howto?com.pooq.hendrik.howto 
> --branch=com.pooq.hendrik.howto howto
> mtn: connecting to 'mtn://topoi.pooq.com/howto'
> mtn:   include pattern  'com.pooq.hendrik.howto'
> mtn:   exclude pattern  ''
> mtn: finding items to synchronize:
> mtn: successful exchange with 'mtn://topoi.pooq.com/howto'
> mtn:  bytes in | bytes out | certs in
> mtn:   351 |   701 |  0/0
> mtn: misuse: branch 'com.pooq.hendrik.howto' is empty
> hendrik@midwinter:~$
> 
> and listing the branches agrees.
> 
> hendrik@midwinter:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
> hendrik@midwinter:~$ 
> 
> The thing is, listing the branches on the server does *not* agree:
> 
> hendrik@april:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
> com.pooq.topoi.howto
> hendrik@april:~$ 
> 
> (yes, the computer identifying itself as april in indeed also topoi.  
> That's not the problem)
> 
> Somehow I've missed out on doing something.  I'm hoping other eyes will 
> see what I don't.
> 
> Here's are the relevant usher stanzas I use on the server
> 
> userpass"hendrik" "notmypassword"
> monotone"/usr/bin/mtn" "-k" "hend...@topoi.pooq.com"
> listenaddr  "0.0.0.0:4691"
> adminaddr   "127.0.0.3:12345"
> logdir  "/farhome/hendrik/monotone/usher-log/"
> 
> server  "howto"
> host"0.0.0.0"
> pattern "com.pooq.topoi.howto"
> local   "-d" "/farhome/hendrik/.monotone/databases/howto.mtn"
> 
> -- hendrik
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

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

[Monotone-devel] erase default sync location (Was: Trouble cloning)

[Hendrik Boom]

The quoted message describes trouble I've had cloning a database.

I have subsequently cloned another database between the same 
server/client pair, but am still having trouble with the original 
database.

I suspect there is something deeply sick in the howto.mtn database, and 
I don't need advice about cloning it.

It had a history.

I had accidentally deleted it a while ago, then restored it from 
backup.

I had another version of it on a client machine (a different one), and 
synced the one on the client with the one on the server.  After syncing 
and updating workspaces on both client and server, everything seemed to 
be OK.

But now it looks as if it wasn't.

Not sure what to do now.

I could copy the entire database from the client to replace the one on 
the server.  But then the server would have itself as a default sync 
location, which might not be best practice.

How can I remove the default sync location?

-- hendrik

On Thu, Jun 28, 2018 at 08:03:23AM -0400, Hendrik Boom wrote:
> I'm sorry to be asking basic usage questions again.
> 
> I have no trouble with the everyday use of monotone -- mind you, the 
> everyday commands are add, drop, sync, and update and they are pretty 
> simple once everything has been set up.
> 
> But I don't clone often.  I don't set up new databases often, and I 
> regret to say that I still need to ask on this list every time I do it.  
> I always seem to do something wrong.
> 
> Today it's cloning a database from a server to a new machine.
> 
> Is clone even the right way to do this?  I could perhaps fall back 
> to the more specific nonamalgameted commands.
> 
> hendrik@midwinter:~$ mtn clone --db=~/.monotone/databases/howto.mtn --key 
> hend...@midwinter.topoi.pooq.com 
> mtn://topoi.pooq.com/howto?com.pooq.hendrik.howto 
> --branch=com.pooq.hendrik.howto howto
> mtn: connecting to 'mtn://topoi.pooq.com/howto'
> mtn:   include pattern  'com.pooq.hendrik.howto'
> mtn:   exclude pattern  ''
> mtn: finding items to synchronize:
> mtn: successful exchange with 'mtn://topoi.pooq.com/howto'
> mtn:  bytes in | bytes out | certs in
> mtn:   351 |   701 |  0/0
> mtn: misuse: branch 'com.pooq.hendrik.howto' is empty
> hendrik@midwinter:~$
> 
> and listing the branches agrees.
> 
> hendrik@midwinter:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
> hendrik@midwinter:~$ 
> 
> The thing is, listing the branches on the server does *not* agree:
> 
> hendrik@april:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
> com.pooq.topoi.howto
> hendrik@april:~$ 
> 
> (yes, the computer identifying itself as april in indeed also topoi.  
> That's not the problem)
> 
> Somehow I've missed out on doing something.  I'm hoping other eyes will 
> see what I don't.
> 
> Here's are the relevant usher stanzas I use on the server
> 
> userpass"hendrik" "notmypassword"
> monotone"/usr/bin/mtn" "-k" "hend...@topoi.pooq.com"
> listenaddr  "0.0.0.0:4691"
> adminaddr   "127.0.0.3:12345"
> logdir  "/farhome/hendrik/monotone/usher-log/"
> 
> server  "howto"
> host"0.0.0.0"
> pattern "com.pooq.topoi.howto"
> local   "-d" "/farhome/hendrik/.monotone/databases/howto.mtn"
> 
> -- hendrik
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

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

[Monotone-devel] Trouble cloning

[Hendrik Boom]

I'm sorry to be asking basic usage questions again.

I have no trouble with the everyday use of monotone -- mind you, the 
everyday commands are add, drop, sync, and update and they are pretty 
simple once everything has been set up.

But I don't clone often.  I don't set up new databases often, and I 
regret to say that I still need to ask on this list every time I do it.  
I always seem to do something wrong.

Today it's cloning a database from a server to a new machine.

Is clone even the right way to do this?  I could perhaps fall back 
to the more specific nonamalgameted commands.

hendrik@midwinter:~$ mtn clone --db=~/.monotone/databases/howto.mtn --key 
hend...@midwinter.topoi.pooq.com 
mtn://topoi.pooq.com/howto?com.pooq.hendrik.howto 
--branch=com.pooq.hendrik.howto howto
mtn: connecting to 'mtn://topoi.pooq.com/howto'
mtn:   include pattern  'com.pooq.hendrik.howto'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: successful exchange with 'mtn://topoi.pooq.com/howto'
mtn:  bytes in | bytes out | certs in
mtn:   351 |   701 |  0/0
mtn: misuse: branch 'com.pooq.hendrik.howto' is empty
hendrik@midwinter:~$

and listing the branches agrees.

hendrik@midwinter:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
hendrik@midwinter:~$ 

The thing is, listing the branches on the server does *not* agree:

hendrik@april:~$ mtn -d ~/.monotone/databases/howto.mtn list branches
com.pooq.topoi.howto
hendrik@april:~$ 

(yes, the computer identifying itself as april in indeed also topoi.  
That's not the problem)

Somehow I've missed out on doing something.  I'm hoping other eyes will 
see what I don't.

Here's are the relevant usher stanzas I use on the server

userpass"hendrik" "notmypassword"
monotone"/usr/bin/mtn" "-k" "hend...@topoi.pooq.com"
listenaddr  "0.0.0.0:4691"
adminaddr   "127.0.0.3:12345"
logdir  "/farhome/hendrik/monotone/usher-log/"

server  "howto"
host"0.0.0.0"
pattern "com.pooq.topoi.howto"
local   "-d" "/farhome/hendrik/.monotone/databases/howto.mtn"

-- hendrik


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

[Monotone-devel] monotone documentation

[Hendrik Boom]

I just noticed -- section "4.4 Network" ot the command reference at 
https://www.monotone.ca/docs/Network.html#Network
doesn't actually say what push and pull do.

-- hendrik


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

[Monotone-devel] Multiple databases

[Hendrik Boom]

Through some kind of incompetence, I seem to have ended up after years 
of use with multiple monotone databases with the same name.  I don't 
even know if their histories are compatible or whether they have nothing 
at all to do with each  other.  Desiring to have only one (except for 
sync-style redundance), and that one being valid and up-to-date, I'm 
going to have to examine them to see what's in them, and how they 
differ.

What tools or practices would expedite this endeavour?

-- hendrik



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

[Monotone-devel] monotone has disappeared from testing.

[Hendrik Boom]

Just noticed that monotone is no longer available in Debian testing:

FYI: The status of the monotone source package in Debian's testing
distribution has changed.

  Previous version: 1.1-9 Current version:  (not in testing)
  Hint: 
Bug #888089: botan1.10 EOL # in botan1.10 # 888612,889556

The script that generates this mail tries to extract removal reasons from
comments in the britney hint files. Those comments were not originally
meant to be machine readable, so if the reason for removing your package
seems to be nonsense, it is probably the reporting script that got
confused. Please check the actual hints file before you complain about
meaningless removals.

So has mnootone-viz, by the way.

-- hendrik

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.


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

Re: [Monotone-devel] Monotone on Github?

[Hendrik Boom]

On Thu, 12 Apr 2018 14:36:20 +0200, Markus Wanner wrote:

> On 04/12/2018 07:19 AM, grarpamp wrote:
>> Maybe that calls for iterative local checkout, generating diffs,
>> checking those into github. Haven't looked into it,
>> just didn't see much that looked officialish / current on github for
>> whoever / whatever might come along.
> 
> There's tools to automate that. Doing it by hand certainly isn't worth
> the trouble.

What tools are there?

-- hendrik


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

Re: [Monotone-devel] Monotone on Github?

[Hendrik Boom]

On Tue, Apr 10, 2018 at 03:17:58AM -0400, grarpamp wrote:
> Not really thinking of non self hosting.
> Just a simple commit mirror with project page pointing to
> wherever is authoritative, github ticketing need not be enabled.
> Mostly to satisfy searches made on github, let people play
> readonly with it via local git clones till they get serious and
> go mtn, attracting more devs / debugs / users, gain some
> global search index rank via github, etc.
> The meta benefits of doing so.

Is there now an automated way of mirroring a monotone repository onto github?

-- hendrik

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

Re: [Monotone-devel] Reviving nmonotone-viz

[Hendrik Boom]

On Fri, 02 Mar 2018 17:19:59 -0500, Hendrik Boom wrote:

> On Fri, Mar 02, 2018 at 09:37:54PM +0100, Markus Wanner wrote:
>> On 02/28/2018 07:24 PM, Hendrik Boom wrote:
>> > When I use monotone-viz I get the message
>> > Could not parse dot output
>> 
>> IIRC I have similar issues with monotone-viz (Debian stable). I'm not
>> aware of any replacements.
> 
> My guess is that whatever produces or consumes the dot output, whatever
> that is,  has been updated and is now incompatible with whatever
> consumes or produces it.
> 
> -- hendrik

Does anyone know what the dot output is?  What software consumes it?  
What software produces it?  That might give me a clue where to look to 
find out what has to be done.

Where is the source code repository for monotone-viz?

Who is in charge of it?

-- hendrik


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

Re: [Monotone-devel] monotone-viz

[Hendrik Boom]

On Fri, Mar 02, 2018 at 09:37:54PM +0100, Markus Wanner wrote:
> On 02/28/2018 07:24 PM, Hendrik Boom wrote:
> > When I use monotone-viz I get the message
> > Could not parse dot output
> 
> IIRC I have similar issues with monotone-viz (Debian stable). I'm not
> aware of any replacements.

My guess is that whatever produces or consumes tthe dot output, whatever 
that is,  has been updated and is now incompatible with whatever 
consumes or produces it.

-- hendrik

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

[Monotone-devel] monotone-viz

[Hendrik Boom]

When I use monotone-viz I get the message
Could not parse dot output

hendrik@notlookedfor:~/dv/text/mt3prod$ monotone-viz  --version
monotone-viz 1.0.2 (base revision: )
Copyright (C) 2004-2006 Olivier Andrieu 
hendrik@notlookedfor:~/dv/text/mt3prod$ 


Is there some other program for visualizing the history of a monotone 
repository? 

Or has monotone-viz advanced beyond the one in my distro (Devuan, more 
or less equivlent to  Debian stable, except for no systemd) and I should 
get current source?

-- hendrik


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

[Monotone-devel] solved: anonymous access again.

[Hendrik Boom]

On Thu, Mar 16, 2017 at 03:51:04PM -0400, Hendrik Boom wrote:
> Once again I am trying to set up a new database on my server and 
> clone it to my development machine.  I am slowly building up a cheat 
> sheet with everything I have to do, but one thing still appears to 
> escape me.

Got it:

mtn read --db=~/.monotone/databases/text.mtn  
> When I try to clone, I discover I am anonyous.
> hendrik@notlookedfor:~/dv/text$ mtn clone --key 
> hend...@notlookedfor.topoi.pooq.com --db ~/.monotone/databases/text.mtn 
> "mtn://topoi.pooq.com/text?com.pooq.hendrik.text*" 
> --branch=com.pooq.hendrik.text.mt3 mt3 
> mtn: connecting to 'mtn://topoi.pooq.com/text'
> mtn:   include pattern  'com.pooq.hendrik.text*'
> mtn:   exclude pattern  ''
> mtn: finding items to synchronize:
> mtn: warning: protocol error while processing peer mtn://topoi.pooq.com/text: 
> 'received network error: anonymous access to branch 
> 'com.pooq.hendrik.text.mt3.dev' denied by server'
> mtn:  bytes in | bytes out | certs in
> mtn:   103 |   349 |0
> mtn: error: processing failure while talking to peer 
> 'mtn://topoi.pooq.com/text', disconnecting
> hendrik@notlookedfor:~/dv/text$ 
> 
> What do I have to do to make myself not anonymous?
> 
> -- hendrik
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

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

Re: [Monotone-devel] SHA- collision found

[Hendrik Boom]

On Sat, Feb 25, 2017 at 12:52:14AM -0500, grarpamp wrote:
> To be in some relative perspective, there are probably lot
> more fixes, updates, and developments to do for monotone
> more important than immediate practicality of sha1 attack
> this very moment. So all those can come as can be made :)

At least one source repository has been completely corrupted by adding 
two pdf's with the same SHA1 hashes.  Granted, it was a Subversion
repository (for Webkit) and not monotone, but the problem may be 
urgent and important.

https://soylentnews.org/article.pl?sid=17/02/26/1724226

How to fix?

(1) start using a better hash code for all new files we commit, so 
that no *new* files will cause a conflict if there isn't already on 
ein the data base.

(2) provide a mechanism for recertifying all the old changes.  Perhaps 
a second-order certificate that certifies all the old certificates s 
being valid.  This would at least be a bit of a mess, because old 
repositories will have both hashes -- old hashes for old changes and 
new ones for new files. 

Or is there a valid way of rehashing and recertifying everything and  
starting afresh with a completely new database?

-- hendrik

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

Re: [Monotone-devel] where is the repository for monotone nowadays?

[Hendrik Boom]

On Tue, Jun 28, 2016 at 05:14:44PM +0200, Markus Wanner wrote:
> On 06/28/2016 04:55 PM, Hendrik Boom wrote:
> > I tried to update my repository for monotone that I had downloaded
> > a few years ago, and it seems not to be able to find the main repository.
> > Where is inowadays?
> 
> Hm.. the website seems down. I'll take care soon-ish.

That would probably explain the problem.  I'll just wait and retry.

-- hendrik

\> 
> >From the top of my head:
> "monotone.ca/monotone?net.venge.monotone"
> 
> Regards
> 
> Markus
> 

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

[Monotone-devel] where is the repository for monotone nowadays?

[Hendrik Boom]

I tried to update my repository for monotone that I had downloaded
a few years ago, and it seems not to be able to find the main repository.
Where is inowadays?

-- hendrik


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

Re: [Monotone-devel] monotone-viz problem

[Hendrik Boom]

On Tue, Jun 28, 2016 at 04:28:21PM +0200, Markus Wanner wrote:
> On 06/28/2016 03:49 PM, Hendrik Boom wrote:
> > Should I file an official bug report?  Or is my note on the monotone 
> > devel mailing list sufficient?
> 
> It's sufficient for me to write the package. It helps in the package
> getting accepted in Debian, if there's a third-party RFP. So, yes,
> please file the "official" RFP. Thanks.

Sorry.  I wasn't clear.  I was referring to the problem with 
monotone-viz being unable to parse dot output.

Or should I invesigate the problem myself?  If so, where do I find the 
upstream repository for monotone-viz?  Presumably there's a monotone 
repository for it somewhere.

-- hendrik

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

Re: [Monotone-devel] monotone-viz problem

[Hendrik Boom]

On Tue, Jun 28, 2016 at 09:43:42AM +0200, Markus Wanner wrote:
> On 06/26/2016 09:22 PM, Anthony Edward Cooper wrote:
> > I wrote mtn-browse but haven't got involved in the packaging. There's only 
> > so much free time... Others have fine excellent work on packaging it for 
> > redhat, but that doesn't help you.
> > 
> > One can easily install mtn-browse under /opt and the installer will 
> > highlight missing dependencies.
> 
> Mind filing a RFP (request for packaging)?
> 
> I already maintain monotone and monotone-viz for Debian.

Should I file an official bug report?  Or is my note on the monotone 
devel mailing list sufficient? 

-- hendrik

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

Re: [Monotone-devel] monotone-viz problem

[Hendrik Boom]

On Fri, Jun 24, 2016 at 10:50:56PM +0100, Anthony Edward Cooper wrote:
> Yes the dot format does change and get tweaked/updated. It has 
> probably changed too much for the aging monotone-viz. Is monotone-vis 
> still maintained? It's written in Occaml and as such I don't think it 
> has been touched for years and is probably not maintained at all now.

Ocaml does not scare me.

> I'm being completely biased but mtn-browse also does graph 
visualization like monotone-viz and much more besides. You could give that a 
go...

I neither was aware that mtn-browse existed, nor know where to find 
it.

It does not appear to be in the Debian repositories, and googling it 
provides me with methods to cheat MTN (whatever that is) to browse for 
free.

What *is* the dot output, anyway?

-- hendrik

> 
> Tony.
> 
> On 23 June 2016 23:58:45 BST, Hendrik Boom <hend...@topoi.pooq.com> wrote:
> >On my devuan jessie system, when I start monotone-viz, it always pops 
> >up a message, 
> >
> > Could not parse dot output
> >
> >Is there some subtle version copatibility problem here? Or some thing 
> >weirder?
> >
> >hendrik@notlookedfor:~/dv/im/slides$ mtn --version
> >monotone 1.1 (base revision: 81fa9664405655b13bde971bddd802de25096073)
> >hendrik@notlookedfor:~/dv/im/slides$ monotone-viz --version
> >monotone-viz 1.0.2 (base revision: )
> >Copyright (C) 2004-2006 Olivier Andrieu <oandr...@gmail.com>
> >hendrik@notlookedfor:~/dv/im/slides$ 
> >
> >-- hendrik
> >
> >
> >___
> >Monotone-devel mailing list
> >Monotone-devel@nongnu.org
> >https://lists.nongnu.org/mailman/listinfo/monotone-devel
> 
> -- 
> See www.coosoft.plus.com.

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

[Monotone-devel] monotone-viz problem

[Hendrik Boom]

On my devuan jessie system, when I start monotone-viz, it always pops 
up a message, 

Could not parse dot output

Is there some subtle version copatibility problem here? Or some thing 
weirder?

hendrik@notlookedfor:~/dv/im/slides$ mtn --version
monotone 1.1 (base revision: 81fa9664405655b13bde971bddd802de25096073)
hendrik@notlookedfor:~/dv/im/slides$ monotone-viz --version
monotone-viz 1.0.2 (base revision: )
Copyright (C) 2004-2006 Olivier Andrieu 
hendrik@notlookedfor:~/dv/im/slides$ 

-- hendrik


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

Re: [Monotone-devel] serialization format

[Hendrik Boom]

On Thu, Apr 07, 2016 at 11:49:15PM +0200, Markus Wanner wrote:
> On 04/07/2016 11:37 PM, Stephen Leake wrote:
> > There's a version number in the internal format, so we don't need a flag
> > day (or maybe that was on a branch; anyway, we can add one). We do need
> > to maintain both formats for compatibility with old databases.
> 
> There's a version identifier for things like certs, revs, etc.., yes.
> However, in any case, there's a point in time where monotone stops using
> the old format and starts to use the new one. We can soften the
> migration by prolonging the time between the first release that supports
> a feature until we activate it. (Not that past flag days had a pretty
> narrow window...)

Or perhaps we could use a new-style certificate to certify that each 
old-style certificate is valid.  This might even be secure if the 
ew-style certificates are issued before the old-style ones are 
vulnerable to attack.

-- hendrik


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

Re: [Monotone-devel] serialization format

[Hendrik Boom]

On Wed, Apr 06, 2016 at 07:28:39AM +0200, Markus Wanner wrote:
> On 04/06/2016 05:26 AM, J Decker wrote:
> > If the structures might mutate with time something like json is pretty 
> > brief.
> > if you have high reliability, sqlite for instance will store a blob
> > with only \0 for the 0  and \\ for \ ...
> 
> JSON doesn't handle binary welll, it's a text format. Usually, base64 is
> used for binary data inside JSON - which is neither human readable nor
> space efficient.
> 
> > which results in a copy or shift of data but only a simple comparison
> > if '\\'   kinda like base 254 sorta :)
> > depending on what character happens least you could replace  for
> >  or something ...
> 
> That's nonsense, according to http://stackoverflow.com/a/1443240, the
> JSON spec supports only 94 Unicode characters that can be represented as
> one byte (in UTF-8).
> 
> Nor is there any canonical *and* human readable variant.
> 
> If human readable, I'd currently prefer to try something canonical
> that's still valid YAML.

And if you want it to be human-readable you'd also want to avoid 
visually confusing characters.  No using both 0 and O.  Or using 1, l, 
and I.  Even , and . can be hard to distinguish in soe fonts.

-- hendrik

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

Re: [Monotone-devel] deferred merge

[Hendrik Boom]

On Sat, Mar 26, 2016 at 09:44:57AM -0400, Hendrik Boom wrote:
> On Sat, Mar 26, 2016 at 10:35:14AM +0100, Markus Wanner wrote:
> > On 03/26/2016 04:46 AM, Hendrik Boom wrote:
> > > Is there some easy oe-time way of asking a merge to be deferred,
> > 
> > Not really, no. Like a commit, this is an atomic operation: either the
> > resulting revision has one (commit) or two (merge) parents. So you can
> > only defer the merge completely. That works pretty well and may be
> > reasonable. For long lived diverges, I usually give one of the branches
> > a specific name.
> > 
> > > so 
> > > that the "merged" file has both versions in it, complete with 
> > > '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?
> > 
> > Well, you can always commit the file including these markers. However,
> > they have no special meaning for monotone and things might get messy
> > with further merges on that same file.
> 
> Thank you.
> 
> Yes, I figured it out.  The trick is not to do any merging in the emacs 
> merge operation, but to click into the merge buffer and save it, 
> telling it yes I mean it when it protests.
> 
> Then, of course, use mmore leisurely tools to analyse the resulting 
> mess and commmit when all those markers are gone.
> 
> Leaving markers around for yet another merge operation would probably 
> invite disaster.

Actually, this new method works pretty well.  It resolves all the 
conflicts that it can by itslef using the usual techniques, and leaves 
me the ones that require thought.  

Normally if it goes to an emacs merge, I get to settle all of them, 
even the obvious ones.

-- hendrik

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

Re: [Monotone-devel] deferred merge

[Hendrik Boom]

On Sat, Mar 26, 2016 at 10:35:14AM +0100, Markus Wanner wrote:
> On 03/26/2016 04:46 AM, Hendrik Boom wrote:
> > Is there some easy oe-time way of asking a merge to be deferred,
> 
> Not really, no. Like a commit, this is an atomic operation: either the
> resulting revision has one (commit) or two (merge) parents. So you can
> only defer the merge completely. That works pretty well and may be
> reasonable. For long lived diverges, I usually give one of the branches
> a specific name.
> 
> > so 
> > that the "merged" file has both versions in it, complete with 
> > '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?
> 
> Well, you can always commit the file including these markers. However,
> they have no special meaning for monotone and things might get messy
> with further merges on that same file.

Thank you.

Yes, I figured it out.  The trick is not to do any merging in the emacs 
merge operation, but to click into the merge buffer and save it, 
telling it yes I mean it when it protests.

Then, of course, use mmore leisurely tools to analyse the resulting 
mess and commmit when all those markers are gone.

Leaving markers around for yet another merge operation would probably 
invite disaster.

-- hendrik

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

Re: [Monotone-devel] I'd like a handy checklist for diagnosing privilege problems.

[Hendrik Boom]

On Sat, Feb 20, 2016 at 05:37:39PM -0500, Hendrik Boom wrote:
> Once again I'm setting up a mtn data base and am having problems with
> privileges.

Before you waste time investigating this, I've already foud one 
problem, thanks to rereading my own message a few days later in a 
different mindset in a coffeeshop.  It seems to have the wrong uri to 
connect to!

> mtn: connecting to 'mtn://topoi.pooq.com/www'

'www' should hae been 'howto'.

No wonder it blocked me.  It would have been nice if usher had a better 
message, such as that my branch ID didn't match the pattern it had for 
www, but it does look as it that was the problem.

Not sure how the www got into my URI.

Still, a checklist would be convenient.

I'll try to write one someime.

-- hendrik

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

[Monotone-devel] I'd like a handy checklist for diagnosing privilege problems.

[Hendrik Boom]

Once again I'm setting up a mtn data base and am having problems with
privileges.

Anyone have a handy checklist for diagnosing privilege problems?
All it tells me is that it's refusing a anonymous conection.

hendrik@notlookedfor:~/howto$ mtn sync --key hend...@notlookedfor.topoi.pooq.com
mtn: connecting to 'mtn://topoi.pooq.com/www'
mtn:   include pattern  'com.pooq.hendrik.howto'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: warning: protocol error while processing peer mtn://topoi.pooq.com/www: 
'received network error: rejected attempt at anonymous connection for write'
mtn:  bytes in | bytes out | revs in
mtn:78 |   349 |   0
mtn: error: processing failure while talking to peer 
'mtn://topoi.pooq.com/www', disconnecting
hendrik@notlookedfor:~/howto$ 

I did manage to pull from the server, creataing a database.
I checked out from the local database.
I made changes locally and committed them.
Now I try to sync and failing.

Evidently I need write permissions.

Now write permission should have been enabled, because the
.monotone/write-permissions file on the server is

hend...@topoi.pooq.com
hendrik-port...@topoi.pooq.com
hend...@notlookedfor.topoi.pooq.com

I have told the server database to read a packet containing the  public key of 
hend...@notlookedfor.topoi.pooq.com.

Evidently, it recognised me when I cloned the database from the server to the 
client.

So I'm puzzled why it doesn't recognise me when I sync.

-- hendrik


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

Re: [Monotone-devel] [Crypto-practicum] Monotone's usage of SHA1

[Hendrik Boom]

On Tue, Feb 16, 2016 at 11:53:55AM -0800, Bill Cox wrote:

> than git, since Monotone does intend to provide data integrity against
> malicious attackers.

Yay!

-- hendrik

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

Re: [Monotone-devel] usher documentation

[Hendrik Boom]

On Sat, 21 Nov 2015 21:40:06 -0600, Timothy Brownawell wrote:

> On 11/21/2015 07:47 PM, Hendrik Boom wrote:
>> Where does usher documentation hide out now?
> It's in doc/documentation.html . I don't know that this is available
> online anywhere other than thru viewmtn.

Found it in the source code, shich I still had lying around.  Thanks.

> 
>> I'm specfically looking to find out how to get usher to reread the
>> configuration file.
> It tries to be a good Unix daemon, and catches SIGHUP for this. There's
> also a command thru usherctl.

Either it didn't work, or I don't know how to SUGHUP.

I tried kill -1 

After that the usher process was still running, but I couldn't connect to 
it.
Actually killing it completely and then restarting it from scratch made 
it work again.  Upon restarting, of course it read the new configuration.

-- hendrik
> 
>> I suppose I can look up the process id with ps, kill it, and reissue
>> the startup command, but is there a more elegant way?
>>
>> I seem wtill to be running usher-0.99, by the way.  I suppose I should
>> look for a newer one, too.
> That's the only version that was ever released, altho I see
> h:net.venge.monotone.contrib.usher does have later activity.


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

[Monotone-devel] usher documentation

[Hendrik Boom]

Where does usher documentation hide out now?

I'm specfically looking to fine out how to get usher to reread the 
configuration file.

I suppose I can look up the process id with ps, kill it, and reissue the 
startup command, but is there a more elegant way?

I seem wtill to be running usher-0.99, by the way.  I suppose I should 
look for a newer one, too.

-- hendrik


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

[Monotone-devel] puzzling revision history

[Hendrik Boom]

Nothing urgent here. monotone-viz is reporting a puzzling revision 
history, and I'mtryngtofigure out howit could have arisen with the 
rather pedestrian operations I use.

d40c1d1e  branches C and priority
|
V
0d0fb542  branch priority
|
V
e388aa8b  branch priority
|
V
ebf87897  branches C and priority

Well, obviously branches C and priority had been tightly synchronised 
at d40c1d1e, development took place on the priority branch only for a 
few revisions, and then it was merged back to the C branch to 
synchronise them again.

This is all pretry straightforward stuff.

But why is there no arrow from d40c1d1e to ebf87897 and a little merge 
circle?


Isn't ebf87897 a merge between d40c1d1e and e388aa8b?

-- hendrik



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

Re: [Monotone-devel] puzzling revision history

[Hendrik Boom]

On Thu, Apr 30, 2015 at 08:35:38PM +0200, Ludovic Brenta wrote:
 On Thu, 30 Apr 2015 14:26:45 -0400, Hendrik Boom wrote:
 Nothing urgent here. monotone-viz is reporting a puzzling revision
 history, and I'mtryngtofigure out howit could have arisen with the
 rather pedestrian operations I use.
 
 d40c1d1e  branches C and priority
 |
 V
 0d0fb542  branch priority
 |
 V
 e388aa8b  branch priority
 |
 V
 ebf87897  branches C and priority
 
 Well, obviously branches C and priority had been tightly synchronised
 at d40c1d1e, development took place on the priority branch only for a
 few revisions, and then it was merged back to the C branch to
 synchronise them again.
 
 This is all pretry straightforward stuff.
 
 But why is there no arrow from d40c1d1e to ebf87897 and a little
 merge
 circle?
 
 
 Isn't ebf87897 a merge between d40c1d1e and e388aa8b?
 
 Not if ebf87897 was simply mtn approved into branch C.

Ah.  That makes sense.  I've never actually used the mtn approve command,
but I suppose there are other commands that have the same effect, 
presumably if the merged revision is d=identical to one of its 
ancestors.

Thanks.

-- hendrik


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

Re: [Monotone-devel] deleting databases

[Hendrik Boom]

On Sat, Apr 25, 2015 at 08:55:42AM -0500, Stephen Leake wrote:
 Hendrik Boom hend...@topoi.pooq.com writes:
 
  Rereading the tutorial for the first time in years I discovered the llovely 
  command 
 
  $ mtn db init --db=:beth
 
  in section 2.3, which creates a database in a standard location, 
  normally $HOME/.monotone/databases
 
  I immediately tried it out, and created
 
  ~/.monotone/databases/onion.mtn
 
  And, of course, I then wondered how to delete it again.
 
 
  Now I get to ask -- does monotone keep any information on this 
  database  outside of the database itself and the _MTN directories in 
  its workspaces.
 
 No, that is the only persistent storage mtn uses.

That's what I expected, but didn't know.

 
  Because if not, I can delete it with a simple
  rm ~/.monotone/databases/onion.mtn
 
 Yes, that suffices.
 
 Unless, of course, you have synced it somewhere.

Of course.

 
 -- 
 -- Stephe

Thank you.

-- hendrik

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

[Monotone-devel] deleting databases

[Hendrik Boom]

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

$ mtn db init --db=:beth

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

I immediately tried it out, and created

~/.monotone/databases/onion.mtn

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


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

Because if not, I can delete it with a simple
rm ~/.monotone/databases/onion.mtn
but if so, there will be some other bookkeeping to do.

-- hendrik


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

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

[Hendrik Boom]

On Wed, Aug 06, 2014 at 09:44:07AM -0500, Stephen Leake wrote:
 jfl j...@i2pmail.org writes:
 
  I have 2 databases, one with 2 branches and one with 4. I want to
  serve them both from the same machine. 
 
 I have not done this, but I believe the anser is usher: 
 
 http://journal.richard.levitte.org/entries/transparent-usher/

I've done it on Debian; it works.
I thought I used  Debian package for it; but I must have installed 
usher by other means, because I don't seem to have an usher
package installed.  I do know I do *not* have monotone-server installed.
I do have monotone-viz, monotone-doc, monotone installed.

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

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

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

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

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

On Thu, May 15, 2014 at 06:44:42PM +0200, Markus Wanner wrote:
 
 In honor of the founder of this project: Sorry, no, the best tool would
 rather be rust.  ;-)

Causing me to look up rust on the wikipedia.  Yes, it looks useful. 
There's one thing not clear to me from the writeup -- is it possible to 
have structures that are *not* pointed to?

And yes, it looks like rust might be tthe right language, too.

How well does it interface with C++?

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

On Fri, May 16, 2014 at 04:36:08PM +0200, Markus Wanner wrote:
 On 05/16/2014 03:28 PM, Hendrik Boom wrote:
  Unfortunately, it looks like squeeze is going to be picked for 
  long-term support.
 
 Squeeze currently ships monotone-0.48-3.
 
 I don't think this affects build requirements of future releases of
 monotone.
 
 I agree it's an indicator that we better remain netsync compatible back
 to (at least) 0.48.

Yes.  That is indeed the most important point here.
And it's probably not all that hard to do.

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

On Fri, May 16, 2014 at 10:19:05AM -0500, Stephen Leake wrote:
 Hendrik Boom hend...@topoi.pooq.com writes:
 
  Unfortunately, it looks like squeeze is going to be picked for 
  long-term support.
 
 picked by who? The Debian project?

Yes.  Experimentally, to see how well it works, but yes.

-- hendrik

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

Re: [Monotone-devel] minimum requirements

[Hendrik Boom]

On Fri, May 16, 2014 at 07:12:20PM +0200, Markus Wanner wrote:
 
 On Hendrik's wishlist:
  * Debian squeeze (oldstable)
  * Windows XP

I just wanted to mention that I myself am using neither of these platforms,
though I have Windows XP available if I should need it.
It's more that squeeze looks like it's going to be a LTS release for a while,
and there's *lots* of people sticking with Windows XP.  How many of
them use monotone is another question entirely.

I *do* use Debian wheezy and jessie for development, normally using 
Debian's packaged monotone.

 
 
 I would like to explicitly exclude these:
  * Debian oldstable (squeeze)
  * all Ubuntu before precise (i.e. older than the last LTS)

It's  only the LTS argument that made me recommend squeeze.

-- hendrik

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

Re: [Monotone-devel] minimum requirements

[Hendrik Boom]

On Fri, May 16, 2014 at 10:14:03PM +0200, Ludovic Brenta wrote:
 Hendrik Boom hend...@topoi.pooq.com writes:
  It's more that squeeze looks like it's going to be a LTS release for a
  while,
 
 for a while being defined as until February 2016 and not supported
 by Debian itself, see https://www.debian.org/News/2014/20140424.html.
 
 If you yourself don't use Squeeze anymore and if nobody has explicitly
 requested support, there is no point in expending effort on it.

Sounds reasonable.

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

On Tue, May 13, 2014 at 09:08:01AM +0200, Thomas Keller wrote:
 
 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.

monotone should definitely be compilable on C++11.  But it's going to be
a while before all platforms have C++11 compiler.  I'm thinking of 
things like long-term-support Ubuntu and Debian Squeeze, older Mac's 
which do not receive new OS/X's any more, Windows XP machines, and so 
forth.  There are probably even older platforms still in active use 
somewhere.  It's not unusual at all for servers to be running stable 
long-term-support versions of software and foregoing the latest and 
greatest for stability.

I have noo idea how many of these old systems use monotone.

I maintain that monotone should remain compilable on older C++ 
compilers.  At very least, the pre-C++11 version of monotone should be 
its own legacy branch and should continue to receive bugfixes for a 
long time, and should remain net-sync-compatible with the current one.

Of course, the operational questions here are *when* the transition 
should occur, and how long dual-operation should be supported when it 
does.

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

On Tue, May 13, 2014 at 08:04:01PM +0200, Markus Wanner wrote:
 
 Given the (lack of) manpower,

It may take some effort to introduce all the C++11 features being 
discussed here.  Getting rid of things that don't work in C++11, well, 
that's somethingg we'll have to do anyway.  But factoring or 
refactoring in new C++11 features is probably going to cost us more 
time than it saves.  Unless, of course, there are serious plans to 
introduce major new facilities into monotone where the improved clarity 
of the code will benefit us.

 I think it's actually beneficial to the
 project to reduce the variety of supported platforms.

The way we're talking, it almost seems the C++11 is itself a new 
platform.

-- hendrik

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

Re: [Monotone-devel] C++11

[Hendrik Boom]

On Tue, May 13, 2014 at 07:29:08PM +0200, Markus Wanner wrote:
 Hey Hendrik,
 
  Of course, the operational questions here are *when* the transition 
  should occur, and how long dual-operation should be supported when it 
  does.
 
 I think the answer to the dual-operation duration is obvious: Zero. We
 just don't have the man-power.
 
 What do you think would be a good time to switch to C++11?
 
 I'm a bit concerned that botan is switching to C++11. (And just notice
 that botan even states gcc-4.7 as the minimum requirement for 1.11 onwards.)

It's possible that botan may force our hand, whether we want to stay 
with the old C++ or not. 

-- hendrik

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

Re: [Monotone-devel] possible SSL compromise

[Hendrik Boom]

On Wed, Apr 09, 2014 at 08:42:18AM +0200, Zbigniew Zagórski wrote:
 Hello,
 
 On Tue, Apr 8, 2014 at 9:25 PM, Hendrik Boom hend...@topoi.pooq.com wrote:
 
  I've just heard about a potential vulnerability in OpenSSL.  See
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883 for the Debian
  version of this problem.
 
  In particular, the message states
 
  all
  keys used with vulnerable processes will need to be replaced both in
  Debian infrastructure and by all users of this package.
 
  I'm wondering whether monotone use is affected by this problem.
 
 Monotone doesn't use TLS and thus openssl implemtentation of TLS and the
 bug in question specific to TLS _extension implementation_ in openssl.
 This is plain old buffer overrun, or in this case buffer overrun ... [1]

Good.  One less thing to worry  about resecuring.

-- hendrik

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

[Monotone-devel] possible SSL compromise

[Hendrik Boom]

I've just heard about a potential vulnerability in OpenSSL.  See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883 for the Debian 
version of this problem.

In particular, the message states

all
keys used with vulnerable processes will need to be replaced both in
Debian infrastructure and by all users of this package.

I'm wondering whether monotone use is affected by this problem.  I 
don't know if it even uses OpenSSL or some other signature mechanism.

-- hendrik


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

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

[Hendrik Boom]

On Fri, Dec 13, 2013 at 06:16:01PM +0100, Thomas Moschny wrote:
 Hi Hugo,
 
  Really??  It would be a surprise to me that monotone's delta algorithm
  would only be efficient for text files, because I have been using
  monotone for many years on images and pdf files without problem
  regarding performance.
  
  I thought monotone uses xdelta, which is a binary delta algorithm that
  facilitates binary merges that can be easily applied to both text and
  non-text files.
  
  Am I right, or is monotone's delta algorithm only efficient for text
  files?
 
 These are two different things. The fact that Monotone uses xdelta to
 efficiently store different versions of a file is an implementation
 detail, that is not (should not) be visible to the user (well, besides
 the fact that it saves disk storage).
 
 An automatic merging attempt on the other hand happens whenever there's
 a conflict for text files to be solved, and this merging attempt is
 line-based.
 
 Do not confuse them, they have nothing to do with each other.
 
 That said, if I remember correctly, one could hook in any other method
 for trying an automatic merge in case of a conflict on file contents,
 and that method could in theory also handle binary files (like zipped
 xml and the like).

Yes, exactly correct.  Or at least, as I recall, too.

There is a merge hook.  And it could be user-coded to check on file 
type and subsequetly use the default merger, or any other,

The big question is whether custom mergers have been written for 
particular file types.  And whether they are easy to write.  SOmetimes 
a back-and-forth conversion to a more mergable file type is the best 
remmedy.

But let me discuss how bad this can get,

There's trouble when merging files with large, heavily nested bracket 
structures.  The default line-by-line mechanism can end up with 
mismatched brackets.  Now this is no problem when processing, say, C 
code, because the textrual level is the level at which human beings 
intereat with the code in an editor, even though the compiler may barf.
But with syntactic trees that the user never  sees, such as the 
einormousy complicated word-processor data structures, when the word 
processor barfs, the user is clueless.

The answer would seem to be to do write secialized merge tools that 
respect brackets.  This can be done, say for an XML file that consists 
of a sequence of records (with one XML tag) containing fields (of 
specific other XML tags) which may contain some further structure.
In other words, where every kind of entity has its own fixed place in 
the nesting hierarchy, and they are normally kept in the same order.
  
But for bracketed tree structures where the nesting can vary, where you 
cah, say, wrap an extra while loop around a bunch of statements, there 
is no known efficient algorithm (at least the last time I looked; 
anybody know better?).  

The only solution as far as I can see to such situations is to change 
the way that data structures are written to a file.  Perhaps give every 
possibly nested entity a unique ID, which you write out with the 
entity to give the merge program something to synchronise on.  Links to those 
entities are then written by writing the unique ID.

The application software must then rigorously maintain these unique IDs 
through processing, editing, and the like,

The application can then write all these entities out in, say, 
alphabetial order.

Such a file would likely be very mergable.

Though you' may still have to worry about parts of the data structure 
accidentally becoming becoming disconnected from the rest.

-- hendrik


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

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

[Hendrik Boom]

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

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

That depends on the file formats.  Monotone does change merging on a 
line-by-line basis,  Most word-processing file formats, for example, 
are terrible at enabling change merging bcause they don't represent 
newlines as new line characters, or because they use data compresssion.
Straight ASCII text, with newlines, is much better, and possibly also 
Microsoft's rich text format (anyone know for sure about this one?)

-- hendrik

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

If it's a txt file, the kind that's memant to be hand-edited, theres 
hope,  What could get in the way is
(1) if the entire txt file is, say, just one line.
(2) if the entire file, as opposed to a few lines, changes wvery tine
the CAD software makes a small change in the design.

Most revision management systems have the same limitations.

With monotone, it's possible to write custom merge rules.  That may be 
complicated, depending on the file format.

-- hendrik

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

[Monotone-devel] Thanks. Re: nested workspaces

[Hendrik Boom]

On Fri, Dec 06, 2013 at 04:31:13AM -0600, Stephen Leake wrote:
 Hendrik Boom hend...@topoi.pooq.com writes:
 
  I've never found a clear discription of what happens with nested workspaces.
  Maybe I just haven't looked enough.
 
  For example, I may have a project and a subproject.
 
  I checkout the project, and get a directory fill of stuff, including a 
  _MTN directory.
 
  Subsequently cd into that and check out another project into a new 
  directory I'll call subproject.  It too has a _MTN directory.
 
  How do these two interact.
 
 badly. But there is a simple workaround; see below.

Presumably the .mtn-ignore that you mention below.

 
  I presume that when I'm in the subproject directory, monotone will see 
  just the subproject.
 
 Yes; it looks for _MTN to indicate the project root.
 
  But when I'm in the main  project, to what extent is monotone aware of 
  the subproject?  
 
 All files/directories in the subproject will appear as 'unknown' to the
 main project.
 
  When doing things like mtn list known, does it see the _MTN file of
  the subproject as a warning not to go there?
 
 No.

Is there ever a case where it *is* useful for monotone in the main project
to be aware of the files of the subproject?
Is there ever a case where it would be useful *not* to mention the root 
directory of the subproject in the .mtn-ignore file?

I'd like to hear of cases where this might actually be useful.  I can 
imagine there might be some, but I can't actually imagine them.

If not, should monotone by default use nested _MTN directories as a 
don't-go-here indicator?

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

(This, and the remaining questions were me testing boundaries for 
clarity, not nnecessarily things I was planning to use.),

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

Yup.

 
  Or can I even go so far as to put the _MTN directories of the 
  subproject under revision control as part of the main workspace? (I 
  suspect this is a bad idea; I'm interested in just what the limits 
  are).
 
 It is a bad idea, because the _MTN/options file contains absolute paths
 that are valid for your machine, but probably invalid for others using
 the project.

Agreed.

 
 The _MTN/revision file changes with each commit.
 
  Or what?
 
 The workaround is to put the subproject root directory in .mtn-ignore
 for the main project. .mtn-ignore should then be committed in the main
 project, which means it has knowledge of the subprojects, reducing
 independence. 

That seems to be what I want.

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

Well, actually, there is.

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

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

I use monotone as a way of being able to use multiple computers 
interchangably, to be able to find old scenes that have been written 
out and have to be resurrected, and, of course, as a backup mechanism.

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

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

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

 
  I'm thinking of using this in a context where the subprojects are 
  really independent projects in their own right, 
 
 Ok.
 
  but the main project contains their workspaces, 
 
 This suggests you are using the term workspace differently than mtn
 does. In mtn, it means the directory tree checked out from one mtn
 branch.

Yes that's the way I'm using the term.

 And project means a set of related branches in a mtn
 repository (more than one branch for parallel development),

There's little parallel development, except transiently, caused by 
occasional failure to sync.  It mmight be different if I ws working on 
multiple-author novels, though

[Monotone-devel] nested workspaces

[Hendrik Boom]

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

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

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

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

How do these two interact.

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

But when I'm in the main  project, to what extent is monotone aware of 
the subproject?  When doing things like mtn list known, does it see 
the _MTN file of the subproject as a warning not to go there?

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

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

Or what?

I'm thinking of using this in a context where the subprojects are 
really independent projects in their own right, but the main project 
contains their workspaces, documentation files that organize the 
collection, and other files that may or may not later become projects 
in their own right.

Assuming this model is feasible, of course.

 -- hendrik
 

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

[Monotone-devel] Workaround for local Makefile changes that are not checked in.

[Hendrik Boom]

On Mon, Aug 19, 2013 at 10:19:25AM -0400, Hendrik Boom wrote:
 
 Exactly why this isn't a great technique.
 
 And why I'll conditionally include a local, not-checked-in, file. 
 Even though it'll cause complications with multiple workspaces -- 
 having to copy the local mods separately from checkout.

And in case anyone is wondering how to include a file into a Makefile
without crashing if the tile isn't there, here's how I did it.

First the default parameters,

AW =
AWC = $(AW)/bin/aw2c

Then the overriding include:

-include LocalMake

Notice the minus sign.

The LocalMake file contains the lines:

AW = /usr/local/stow/aw2c
AWC = $(AW)/bin/aw2c

The LocalMake file is *not* checked into monotone.

It's conceivable I should be using ':=' instead of '=' so I wouldn't 
have to repeat the definition of AWC.  Or maybe that wouldn't help.  
I'm not sure of the semantics here.

-- hendrik

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

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

[Hendrik Boom]

On Mon, Aug 19, 2013 at 02:48:51PM +0200, Markus Wanner wrote:
 On 08/16/2013 10:18 AM, Stephen Leake wrote:
  You could do it manually with the following steps:
  
  - generate a diff file containing the changeset.
  
  - propagate from local to main
 
 Remember that this a) reveals your local changes and b) screws up
 history (i.e. logs and annotate). I usually keep anything that could be
 described as local adjustments private and the upstream clean of such
 adjustments.

Exactly why this isn't a great technique.

And why I'll conditionally include a local, not-checked-in, file. 
Even though it'll cause complications with multiple workspaces -- 
having to copy the local mods separately from checkout.

-- hendrik

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

[Monotone-devel] hangs during netsync

[Hendrik Boom]

I did a netsync with an explicit --db= and a --set-default, because the 
database had moved in the file tree.

It hung after telling me there were no revs out, which was probably 
correct; I think the two databses may well have been previously sync'd. 

hendrik@notlookedfor:~/dv/lang/algol/a68h2/workspace$ mtn sync 
--db=/home/hendrik/dv/lang/algol/a68h2/a68h.mtn --set-default
mtn: warning: could not unregister workspace from old database 
'/home/hendrik/dv/lang/a68h2/a68h.mtn'
mtn: connecting to 'mtn://a68h.mtn-host.prjek.net'
mtn:   include pattern  '*'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:  369 |2 |   123
mtn:  bytes in | bytes out | revs in | revs out
mtn: 1.0 k | 1.4 k |   0 |0

Of course it also told me it could not unregister my workspace from the 
old database, which is probably because the database wasn't there any 
more.  It had been moved, along with the source tree, several 
workspaces, and several other projects, to a new location.

Are the databases still OK?

-- hendrik




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

Re: [Monotone-devel] hangs during netsync

[Hendrik Boom]

On Mon, Aug 19, 2013 at 02:18:32PM -0400, Hendrik Boom wrote:
 I did a netsync with an explicit --db= and a --set-default, because the 
 database had moved in the file tree.
 
 It hung after telling me there were no revs out, which was probably 
 correct; I think the two databses may well have been previously sync'd. 
 
 hendrik@notlookedfor:~/dv/lang/algol/a68h2/workspace$ mtn sync 
 --db=/home/hendrik/dv/lang/algol/a68h2/a68h.mtn --set-default
 mtn: warning: could not unregister workspace from old database 
 '/home/hendrik/dv/lang/a68h2/a68h.mtn'
 mtn: connecting to 'mtn://a68h.mtn-host.prjek.net'
 mtn:   include pattern  '*'
 mtn:   exclude pattern  ''
 mtn: finding items to synchronize:
 mtn: certificates | keys | revisions
 mtn:  369 |2 |   123
 mtn:  bytes in | bytes out | revs in | revs out
 mtn: 1.0 k | 1.4 k |   0 |0

It stayed hung for hours.  Eventually I control-C'd out of it.

The database file name had been updated (I peeked inside _MTN).

A subsequent sync worked fine.

I can no longer repeat the operation to test potential patches, if it 
is a bug instead some weird network glitch.

It does appear that no data were harmed in the course of this problem.

-- hendrik

 
 Of course it also told me it could not unregister my workspace from the 
 old database, which is probably because the database wasn't there any 
 more.  It had been moved, along with the source tree, several 
 workspaces, and several other projects, to a new location.
 
 Are the databases still OK?
 
 -- hendrik
 
 
 
 
 ___
 Monotone-devel mailing list
 Monotone-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/monotone-devel

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

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

[Hendrik Boom]

On Thu, Aug 15, 2013 at 10:04:52AM +0200, Markus Wanner wrote:
 On 08/15/2013 02:22 AM, Hendrik Boom wrote:
  II sometimes have to adapt a package to local conditions -- the most 
  common kind of change is a configuration changem such as specifying where 
  it is to be installed.
  
  Now the obvious (and possibly wrong) is to make a local branch, make this 
  change and propagate changes from the main branch into the local branch 
  whenever it changes.
  
  This works if there is a one-way flow of information from developers 
  elsewhere to my localized branch.
  
  But once the package has been adapted to local conditions, I will often 
  want to continue developing it, using the local configuration.  I can't 
  very well do this development on the main trunk, since it is not adapted 
  to the machine I'm editing, running, and testing on,  So I have to do it 
  on the local branch.
 
 Understood.
 
  When the time comes, I'll want to propagate the changes to the main 
  branch, but I won't want to propagate the local configuration changes to 
  the main branch.
  
  Is there any way to mark this one changeset so that it will never be 
  merged into the main branch?
 
 I usually use branches. They are cheep. Propagation can happen from a
 script. For example:
 
 upstream
   - upstream.local-devel
  - upstream.local-devel.local-adjust

Well, this is more or less what I considered, but local-devel isn't all 
that easy to do without the local-adjust being applied during testing.
And as for editing in the local-adjust during testing and editing it 
out befure commit, well, that's bound to be error-prone.

Of course it would be posssible to do all the editing and static 
checking on upstream.local-devel and the propagate into 
upstream.local-devel-local-adjust before every test run...
Maybe even have the local-devel commit and local-adjust mtn propagate 
command in the Makefile for loocal-adjust.

Hmm.

 
 It's getting a bit more painful if you do the local adjustment first.
 Then I usually end up with four branches:
 
 upstream
   +- upstream.local-adjust   --,
   '- upstream.local-devel  v
   '- upstream.local-devel.local-adjust
 
 Especially in case you keep modifying your local adjustments, merges can
 get a bit cumbersome, yes.
 
  Or am I approaching this issue entirely in the wrong manner?
 
 In a way, branches are (part of) that tagging of how to merge. At least
 together with a script that remembers the ways to propagate between
 branches.
 
 I don't think forbidding a single changeset in any other way is
 feasible. After all, you might eventually want to switch forth and back
 between the variant with your local adjustments and the one without.

I don't even think there's a mechanism for forbidding a single 
changeset to propagate.  I do wish there was.  As for switching back 
and forth, I can still use the local-adjustment branch as needed.

Hmm.  Another possibility is for the Makefile -- or whatever else -- to 
conditionally include a separate local-options file -- conditional on 
there being one.  Never check in that local-options file, even locally.
But there are enough tools whose input doesn't have any mechanism for 
this to make it awkward.

-- hedrik

 
 Regards
 
 Markus Wanner

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

[Monotone-devel] Forbid a changeset from merging

[Hendrik Boom]

II sometimes have to adapt a package to local conditions -- the most 
common kind of change is a configuration changem such as specifying where 
it is to be installed.

Now the obvious (and possibly wrong) is to make a local branch, make this 
change and propagate changes from the main branch into the local branch 
whenever it changes.

This works if there is a one-way flow of information from developers 
elsewhere to my localized branch.

But once the package has been adapted to local conditions, I will often 
want to continue developing it, using the local configuration.  I can't 
very well do this development on the main trunk, since it is not adapted 
to the machine I'm editing, running, and testing on,  So I have to do it 
on the local branch.

When the time comes, I'll want to propagate the changes to the main 
branch, but I won't want to propagate the local configuration changes to 
the main branch.

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

Or am I approaching this issue entirely in the wrong manner?

-- hendrik
 


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

[Monotone-devel] resizing monotone-viz

[Hendrik Boom]

Is there a reason why monotone-viz doesn't let me shrink its window?  I 
find its minimun size to be just a little too big to fit on my laptop 
screen.

-- hendrik


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

Re: [Monotone-devel] cvs_import

[Hendrik Boom]

On Wed, Jul 17, 2013 at 08:47:54PM +0200, Markus Wanner wrote:
 Hendrik,
 
 On 07/15/2013 07:21 PM, Hendrik Boom wrote:
  Just wondering what the current status of of monotone's CVS support;
  in particular, cvs_import, csv_pull. cvs_sync, cvs_takeover, and I've 
  heard there's even a cvs_push.
 
 Standard monotone's cvs_import works fine for simple cases. I didn't do
 any work on the cvs_import branch and I don't think it's in a usable state.

So standard monotone's cvs_import is different from what's on the 
cvs_iport branch, as described on http://wiki.monotone.ca/CvsImport/, 
even assuming that page is up to date.

And there's also 
http://wiki.monotone.ca/Branches/nvm.cvsimport-branch-reconstruction/

which bears your name and says Status: Work in Progress Still 
close to completion.  Do you know if that status is still valid?  or 
if anyone else might have worked on it or be on the case?

Is it still worth doing?

 
 You might want to check if cvs2svn can be of help. They have a nice git
 export function and their CVS sanitizer code is field proven. I'm not
 sure if you can get that into monotone, though.
 
  Is the conversion a one-time event, or can it keep up with further 
  revisions on the cvs site withoug having to start over?
 
 There are all one-time conversion options, which need access to the RCS
 files on the CVS server.
 
 tailor may be an option, if you want a continuous mirror.

THe main need for a continuous mirror I see would be during transition 
from CVS to monotone. There would likely be work in progress on the 
old system while the new one is being adopted.

 It certainly
 has a monotone plugin. I'm not sure what the status of cvs_sync is, but
 it's intended to provide continuous synchronization as well.

tailor (http://darcs.net/RelatedSoftware/Tailor)looks interesting, 
thanks.

-- hendrik

 
 Regards
 
 Markus Wanner

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

Re: [Monotone-devel] capacity

[Hendrik Boom]

On Tue, Jul 16, 2013 at 08:22:28PM +0200, Zbigniew Zagórski wrote:
 Hello,
 
 On Mon, Jul 15, 2013 at 7:24 PM, Hendrik Boom hend...@topoi.pooq.com wrote:
 
  Just wondering -- is there a limit on the size of a monotone repository?
  I figure it's limited by the maximum file size on the file system, but
  now that those limits have gone way over 4 gigabytes, has monotone's
  data base backend kept up?
 
 Monotone uses sqlite3, and it's limits are described here:
 http://www.sqlite.org/limits.html.
 
 Page size of monotone db is 8192 (at least my databases are something
 like that), max database size is something like 8192 * 2^31 should be
 enough for any sane monotone database.

Thanks.  The link you provided tells me that although the maximum size 
of a database is normally 1073741823, although it can be set at 
compile tome to 2147483646.

So it looks like the max database is something like 8192*2^30 in 
practicd.

Still, as you said, it looks to be large enough.

 
 So in theory it should handle huge databases ...
 
 --
 Zbigniew Zagórski
 / software developer / geek / http://zbigg.blogspot.com /

-- hendrik


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

[Monotone-devel] cvs

[Hendrik Boom]

Just wondering what the current status of of monotone's CVS support;
in particular, cvs_import, csv_pull. cvs_sync, cvs_takeover, and I've 
heard there's even a cvs_push.

Do any of these work well?  Do they come close to importing most of the 
history in an intelligible way?

Is the conversion a one-time event, or can it keepp up with further 
revisions on the cvs site withoug having to start over?

-- hendrik


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

[Monotone-devel] capacity

[Hendrik Boom]

Just wondering -- is there a limit on the size of a monotone repository?
I figure it's limited by the maximum file size on the file system, but 
now that those limits have gone way over 4 gigabytes, has monotone's 
data base backend kept up?

-- hendrik

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

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

[Hendrik Boom]

On Fri, Mar 15, 2013 at 10:35:29PM +, Richard Hopkins wrote:
 --- On Fri, 15/3/13, Markus Wanner mar...@bluegap.ch wrote:
  To me, it looks like dynamic_pointer_cast is old enough to
  be usable for
  us. At least according to their documentation, it is
  included since 1.34:
  
 One of my installs has boost 1.36 and your commit (dfe4b)
 compiles fine on it.
 
 My vote is for a release soon ;-)

For reference, Debian stable has libboost packages with versin number 1.42.0-4.

-- hendrik

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

[Monotone-devel] segmentation fault

[Hendrik Boom]

I left out the --db when creating a new monotone database.
I might expect to be chided with an error message, but not to
get a segmentation fault:

hendrik@notlookedfor:~/monotone$ mtn db init free-fun
mtn: fatal signal: Segmentation fault
this is almost certainly a bug in monotone.
please send this error message, the output of 'mtn version --full',
and a description of what you were doing to 
https://code.monotone.ca/p/monotone/issues/
do not send a core dump, but if you have one, 
please preserve it in case we ask you for information from it.
Segmentation fault
hendrik@notlookedfor:~/monotone$ 

Actually, even doing the following is trouble:

hendrik@notlookedfor:~/monotone$ mtn version --full
mtn: fatal signal: Segmentation fault
this is almost certainly a bug in monotone.
please send this error message, the output of 'mtn version --full',
and a description of what you were doing to 
https://code.monotone.ca/p/monotone/issues/
do not send a core dump, but if you have one, 
please preserve it in case we ask you for information from it.
Segmentation fault
hendrik@notlookedfor:~/monotone$ 

So I think something is seriously wrong.  Is my executable corrupt?

In case it helps, 

hendrik@notlookedfor:~/monotone$ md5sum /usr/bin/mtn
3b0c8c24bcb6edf22f7f5935c0a91ca2  /usr/bin/mtn
hendrik@notlookedfor:~/monotone$ 

aptitude tells me I have monotone 1.0-6, monotone-extras 1.0.6, and
monotone-doc 1.0.6, all on a Debian wheezy system that was upgraded 
about two days ago.

-- hendrik


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

Re: [Monotone-devel] segmentation fault

[Hendrik Boom]

On Thu, Jul 12, 2012 at 12:44:01AM +0200, Ludovic Brenta wrote:
 See http://bugs.debian.org/681066
 
 -- 
 Ludovic Brenta.

Thanks.  I downloaded the 1.20.3 botan from packaes.debian.org and 
installed it with dpkg.   It all works fine now.

-- hendrik

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

Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict

[Hendrik Boom]

On Thu, Jun 14, 2012 at 08:06:42AM -0400, Stephen Leake wrote:
 Ethan Blanton e...@psg.com writes:
 
  An alternate is to live with the 'ignoring upstream changes due to local
  delete' warning in 1.0.
  
  Why is that not ok?

How would monotone know which is upstream and which is downstream?

-- hendrik

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

Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)

[Hendrik Boom]

On Fri, Jun 08, 2012 at 02:53:30PM +0200, Markus Wanner wrote:
 
 
 Sorry, that was too brief. I'll give an example:
 
 A
/ \
  M1   D
   | \ |
   |   P-- P is the keep resolution, effectively resurrecting
   |   |-- the file and giving it a new node id.
   |   |
  M2   |-- M2 and M3 are both modifications on the same file (but
   |   M3   -- now known under different node ids).
\ /
 Q  -- Q merges. How?
 
 The issue you are facing in Q is that monotone thinks the two node ids
 are distinct files. Even if you manage to teach it to suture because
 the two files conflict by their path, figuring out what ancestor to use
 is non-trivial. And certainly involves remembering the relation of the
 file added in P to the one deleted in D (or modified in M1, same thing,
 same node id).

What I've not managed to understand through this whole discussion is why 
at P the file has to be given a new node id.  Why can't it have the one 
it had at M1?  That's what it would have happened if it had been added 
at M1 instead of being deleted at D.

-- hendrik

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

Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict

[Hendrik Boom]

On Fri, Jun 08, 2012 at 02:24:48PM +0200, Markus Wanner wrote:
...
...

  My prefered solution for that case would be to split the project into
  five (or more) projects; win32 support, unix support, common
  project; release project 1 contains common, unix, and win32; release
  project two contains common and unix.
 
 Now assume the parent project is not under your control. Your preferred
 solution is to split the project into different branches and you want to
 do that in your fork. In the win32 branch, you certainly don't ever want
 the unix files. And vice versa. You delete them. And you are cento
 percento sicuro you don't ever want to see them again.
 
 The parent project continues as it did before. You want to propagate
 their changes to your fork. Every modification from the parent project
 will currently invoke the warning about the modification not being
 visible in your sub-project, because of the files you deleted.

Here we're discussing seriously the case I wondered about ages ago, 
where you want to split a project into several projects, but later 
decide to bring them back together.  You have the problen of decidint=g 
which files to merge, and which files have more-or-less become different 
files, both of which need to be kept.

...
...
 
 In principle, I like the attribute approach better. However, there's the
 technical difficulty of being unable to store attributes on deleted files.
 
 (Also note that during the liveliness tracking and merging discussion,
 Nathaniel brought up the example of OpenEmbedded, who happens to create
 and delete lots of files in their process. So that if monotone never
 really deletes a file, but keeps it in its manifest with an invisible
 attribute or some such, the overhead from deleted files would soon
 surpass the amount of data for live files).

What'd the overhead for deleted files now?  With the problematical 
merges we're discuccing, we have to have some mechanism in place to 
discover that a deletion has been performed in the distant past on one 
of the nerging branches.  Presumably that implementation mechanism would 
suffice -- the file doesn't need to be mentioned in the manifest for us 
to implement this model.

...
...
 
 It just occurs to me that this resembles the case of copying files. For
 a user, it's just copying a file. However, afterward, there are two
 options on how to merge modifications to copied files, which I've seen
 referred to as symmetrical and asymmetrical copy: either the merge
 only adjusts the original file (asym), leaving the copy as is. Or it
 could duplicate that modification as well and apply the modification to
 both files as part of the merge. There exist valid use cases for both
 variants. My point for this discussion is: I think that's another case
 where the user has a better chance of understanding the effects of his
 decision when asked at the time of the merge (instead of at commit time).

It sounds like the same kind of problem.  Merging should just work if 
both sides have the copying in their ancestry.  Otherwise, there are 
decisions to be made, which might even involve line-by-line casuistry.

 
 Complicating things, I don't think it's a file specific decision. Maybe
 there exist use cases where you want to ignore modifications from the
 parent project, but at least want to see a warning, or even better a
 real conflict, if somebody else from your project tried to modify the
 file before seeing your deletion.

It can even be a line-by-line decision.  You deleted this line on branch 
A, but modified it on branch B.  It's a conflict.  What do you want?  Is 
this really any different from the case with files?

...
...

 Comments?

This whole discussion relates to the user-interface for merges.  

When I'm faced with a merge, I'd sometimes like to be able to say, Hey, 
wait a minute, this takes serious thought.  Could you please put all 
this stuff in my workspace without doing the merge, so I can pull out my 
whole development toolkit ans work out what has to be done?  

I'd sometimes even like the possibility of doing the merge a bit at a 
time, each time reporting progress to monotone until it's finally done.

-- hendrik

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

[Monotone-devel] usher locks db

[Hendrik Boom]

Is there a reason for  usher to keep a database locked after the netsync 
is finished?

I just sync'd from my laptop to my server using usher; a subsequent 
attempt to checkout on the server (witout usher, of course) failed 
because the database was locked.

-- hendrik


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

Re: [Monotone-devel] usher locks db

[Hendrik Boom]

On Fri, 25 May 2012 15:59:51 +, Hendrik Boom wrote:

 Is there a reason for  usher to keep a database locked after the netsync
 is finished?
 
 I just sync'd from my laptop to my server using usher; a subsequent
 attempt to checkout on the server (witout usher, of course) failed
 because the database was locked.


Maybe I just didn't wait long enough?  It's unlocked now, several hours 
later.  Are there time-outs?

--hendrik



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

[Monotone-devel] Useful summary of monotone usage

[Hendrik Boom]

I found this web page useful as a summary of common monotone usage:

http://developer.pidgin.im/wiki/UsingPidginMonotone

It's specific for the developer of pidgin, but informative all the same.

-- hendrik


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

[Monotone-devel] How to not be anonymous

[Hendrik Boom]

I hate pestering you guys with trivia, but here goes again.

Every time I set up a new mtn database I end up with trouble.  Always 
it's different trouble.  I don't seem to remember all the details from 
previous times, and I seem to misread the manual again and again.

THis time what's stymied me is anonymity.

I.m trying to populate a database by pulling form an usher server:


hendrik@notlookedfor:~/monotone$ mtn --key hend...@notlookedfor.topoi.pooq.com 
pull mtn://topoi.pooq.com/slides?com.pooq.hendrik.slides --db 
~/monotone/slides.db
mtn: connecting to 'mtn://topoi.pooq.com/slides'
mtn:   include pattern  'com.pooq.hendrik.slides'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: warning: protocol error while processing peer mtn://topoi.pooq.com/slides: 
'received network error: anonymous access to branch 'com.pooq.hendrik.slides' 
denied by server'
mtn:  bytes in | bytes out | certs in
mtn:97 |   350 |0
mtn: error: processing failure while talking to peer 
'mtn://topoi.pooq.com/slides', disconnecting
hendrik@notlookedfor:~/monotone$ 

now, I have the proper permissions to read that remote data base.  
But what do I have to do to be recognised as not being anonymous?
Is  specifying the key with --key hend...@notlookedfor.topoi.pooq.com not 
enough?

-- hendrik


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

Re: [Monotone-devel] [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'

[Hendrik Boom]

On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote:
 On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins s...@debian.org wrote:
  This package failed to build using the newest Boost version 1.48:
 ...
  /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In 
  function 'T boost::math::detail::lgamma_small_imp(T, T, T, const 
  mpl_::int_0, const Policy, const L)':
 ...
  /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38: 
  error: expected primary-expression before 'do'
 
 I'm not in a position to verify this for myself for another week, but
 I have a horrible feeling I know what's wrong:  Monotone defines
 several one-character macros for its own use, and L() is one of them.
 It looks like Boost is using L() for its own purposes and expecting it
 not to be a macro.
 
 I'd argue that Boost headers should take care to defend themselves
 from the possibility of such macros, but fixing that in Boost might be
 an enormous amount of work, and in any case, 1.48 is already out
 there.
 
 If I'm right, this can also be fixed in monotone by moving all Boost
 and stdlib #includes above most-but-not-all application #includes;
 unfortunately that's exactly the opposite coding style from the
 present usage, and may involve messing with the base.hh convention
 (config.h obviously still needs to be the very first thing included in
 every file).

Or by changing the name of L.  This could presumably be done using a 
program on the source code.  It would have to be careful only to change 
L where it was a separate word, outside of strings.  It should flag L's 
in comments for special treatment -- whether it should change them 
automatically should probably depend on whether most L's in comments 
were mantions of the macro or words (unlikey, but might happen in 
abbreviations).

It probably wouldn't even be a long program.  It should run on the C++ 
code, probably not on any code in other languages.  Do we ever do 
token-pasting with L?

-- hendrik

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

Re: [Monotone-devel] monotone-usher or usher-server and usher

[Hendrik Boom]

On Tue, 27 Dec 2011 11:40:16 +0100, Richard Levitte wrote:

 
 Yup, that's not the correct server.  The debian stuff is in
 mtn://code.monotone.ca/debian-mtn
 
 However, considering what I wrote above, that isn't enough either. A
 quick way to do this is:
 
 mtn clone
 mtn://code.monotone.ca/contrib?net.venge.monotone.contrib.usher usher
 cd usher
 mtn clone mtn://code.monotone.ca/debian-mtn?org.debian.usher debian
 
 The correct way is a little bit more complex.  Since Debian packages are
 built from source distributions, the correct way is to build a source
 distribution, unpack that, clone the debian directory inside the
 resulting directory, then build your debian package from there (using
 debuild or pbuilder or whatever you fancy)

So this means I make nested checkouts, without using merge-into-dir
which was supposed to replace nested checkouts.

Is there any documentation on how nested workspaces are supposed to work?

Are these projects sufficiently disjoint that I should keep them in 
separate databases following the each-project-has-its-own-database 
best-practice? Might it make netsync awkward if I don't keep them
separate? Does the local database keep track of which other database 
separate for each branch, or is it just one for all?

-- hendrik


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

Re: [Monotone-devel] monotone-usher or usher-server and usher

[Hendrik Boom]

On Tue, 20 Dec 2011 10:21:19 +0100, Richard Levitte wrote:

 In message 87r500w9om@ludovic-brenta.org on Mon, 19 Dec 2011
 22:09:13 +0100, Ludovic Brenta ludo...@ludovic-brenta.org said:
 
 ludovic ... but TTBOMK nobody has packaged usher yet.  Sorry about
 ludovic that.
 
 There's no final package distributed to Debian, but there's an effort in
 branches org.debian.usher and org.debian.usher.experimental.

So far I've been advised to look at
  org.debian.usher
  org.debian.experimental
and 
  net.venge.monotone.contrib.usher 

Which of these would be most opportune?  Or is there some important 
ancestral relationship between them?  And should I work directly on these 
branches or fork my own?  Maybe something like 
net.venge.monotone.usher.hendrik or is there a better suggestion?

-- hendrik


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

Re: [Monotone-devel] monotone-usher or usher-server and usher

[Hendrik Boom]

On Tue, 27 Dec 2011 01:26:42 +, Hendrik Boom wrote:

 On Tue, 20 Dec 2011 10:21:19 +0100, Richard Levitte wrote:
 
 In message 87r500w9om@ludovic-brenta.org on Mon, 19 Dec 2011
 22:09:13 +0100, Ludovic Brenta ludo...@ludovic-brenta.org said:
 
 ludovic ... but TTBOMK nobody has packaged usher yet.  Sorry about
 ludovic that.
 
 There's no final package distributed to Debian, but there's an effort
 in branches org.debian.usher and org.debian.usher.experimental.
 
 So far I've been advised to look at
   org.debian.usher
   org.debian.experimental
 and
   net.venge.monotone.contrib.usher
 
 Which of these would be most opportune?  Or is there some important
 ancestral relationship between them?  And should I work directly on
 these branches or fork my own?  Maybe something like
 net.venge.monotone.usher.hendrik or is there a better suggestion?
 
 -- hendrik

I'm evidently still doing somethihg wrong -- again -- because after I 
executing

mtn pull mtn://code.monotone.ca/monotone?org.debian.usher

and getting

mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://code.monotone.ca/monotone
mtn: finding items to synchronize:
mtn: successful exchange with mtn://code.monotone.ca/monotone
mtn:  bytes in | bytes out | certs in
mtn:   351 |   525 |  0/0
mtn: note: your workspace has not been updated

and subsequenty (in another directory) doing

mtn checkout --db=~/monotone/monotone.db --branch=org.debian.usher.monotone 
debush

it tells me

mtn: misuse: branch 'org.debian.usher.monotone' is empty

which I might have guessed from the low bytes in and bytes out counts.
Am I talking to the right server?

On the other hand, I have no trouble getting
 net.venge.monotone.contrib.usher
which seems to contain an usher without the init.d stuff to start it at 
boot and keep it up.

-- hendrik


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