monotone on windows
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
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
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
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
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
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?
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?
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?
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?
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
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?
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
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
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?
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
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;
Re: [Monotone-devel] Won't transfer on syncing.
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.
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.
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
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
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
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
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
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
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
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
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
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)
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
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
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
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.
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: <https://release.debian.org/britney/hints/auto-removals> 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?
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?
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
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
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
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 <oandr...@gmail.com> 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.
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
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?
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?
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
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
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
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
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
Re: [Monotone-devel] serialization format
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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'
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
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
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
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