Re: [Monotone-devel] undoing commits
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
Re: [Monotone-devel] undoing commits
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. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
Markus Wanner <mar...@bluegap.ch> writes: > Hello Stephen, > > thanks for your feedback. > > On 04/04/2016 06:58 PM, Stephen Leake wrote: >> Human readable makes testing and developing new features much easier. If >> we use binary, we will need a separate tool that translates that to >> readable, which is then another source of bugs (or the same source, just >> in a different place). > > Yeah, that's a point. However, I'd also argue that we should target the > user and not the developer. And from a user's perspective, isn't > monotone the very tool that does that kind of translation? > > Or put another way: Do *users* really care what serialization format > monotone uses underneath? No but they might care about performance. How much of monotone's time is actually spent translating between binary and hex? Is this really a major performance bottleneck? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] minimum requirements
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. -- Ludovic. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I... well, I quit ;-)
Richard Levitte writes: you may have noticed that I haven't said much of a peep for quite a while. Fact is, I've generally been pulling away from programming as a passion since a few years back. I may still do some to be able to pay the bills, but that's about all. Life changes, life turns, that sort of thing... For those who want to know, I've restarted another passion of mine, photography and art based on that. I may stick around as a translator for a while more, in the hope that someone else turns up to take over that part. How is it these days, is there a translators mailing list or is this the one? I just thought that it was time to make this official instead of just lurking. Sorry to hear that because I've been using monotone daily for the past 8 years now (the first version I evaluated was 0.24) and your work on packaging it for Debian has been instrumental in that. So long, and thanks for all the fish :) I hope your life remains a constant celebration and that it becomes even more fulfilling than it has been so far. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Christmas Release
Thomas Keller wrote: Hi all! The question regarding a new monotone release arose recently... wouldn't it be great to release it as christmas present for the last loyal users we have...? http://qa.debian.org/popcon.php?package=monotone Monotone lives! -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] segmentation fault
See http://bugs.debian.org/681066 -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.lua-5.2 failing on mingw
Stephen Leake wrote: Ludovic Brenta ludo...@ludovic-brenta.org writes: Stephen Leake wrote: So apparently g++ 4.6.2 has problems with exceptions on Mingw. Cygwin is still at 4.5.3; I don't think Debian is at 4.6 yet. So perhaps this is not surprising. Yes, Debian (unstable) is at 4.6 and even transitioning to 4.7 now. Debian stable is 15 months old and at 4.4. So the release plan for Debian is to have 4.7? Yes but that came as a slight surprise and is causing a stir[1,2]. [1] http://lists.debian.org/debian-release/2012/05/msg00175.html [2] http://lists.debian.org/debian-gcc/2012/05/msg00075.html I guess mtn has been tested with unstable recently, so the C++ exception bug appears to be specific to MinGW. I built monotone 1.0-6 yesterday night with g++-4.7 and libbotan1.10-dev with no problems. All the tests passed. I'll wait 3 days for 1.0-5 to reach testing before I upload, though. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.lua-5.2 failing on mingw
Stephen Leake wrote: So apparently g++ 4.6.2 has problems with exceptions on Mingw. Cygwin is still at 4.5.3; I don't think Debian is at 4.6 yet. So perhaps this is not surprising. Yes, Debian (unstable) is at 4.6 and even transitioning to 4.7 now. Debian stable is 15 months old and at 4.4. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone tests failing under Debian automated building
On Tue, 24 Apr 2012 15:04:13 +0100, Francis Russell wrote: To me, it looks like monotone is copying test databases to a specific location for a test, then apparently finding the files missing. I can't replicate this in a Debian unstable chroot, nor can I imagine in the automated build environment could cause the tests to fail in this way. Ha, I've found it! monotone appears to be rewriting pluses to spaces in its URLs: Simple example: $ cd /tmp/ $ mtn db init -d mtn.db $ mtn db init -d mtn+2.db $ mtn pull -d mtn.db file:///tmp/mtn+2.db?* mtn: doing anonymous pull; use -kKEYNAME if you need authentication mtn: connecting to 'file:/tmp/mtn 2.db' mtn: include pattern '*' mtn: exclude pattern '' mtn: misuse: database '/tmp/mtn 2.db' does not exist The plus sign must be percent-encoded as %2B in the URI: mtn pull -d mtn.db file:///tmp/mtn%2B2.db?* -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-usher or usher-server and usher
Hendrik Boom hend...@topoi.pooq.com writes: I found an old message (http://www.mail-archive.com/monotone- deb...@nongnu.org/msg00100.html) mentioning an usher-server and an usher for Debian. At that time there was talk about getting these into debian experimental, or into unstable or testing after the code freeze. Now these look like the recommended way to get usher to start at boot and stay up. But I find no such package now. Where is it, or its code, hiding out? Nowhere :( The package monotone-server automatically configures, and allows a single monotone server instance to start from /etc/init.d/monotone but TTBOMK nobody has packaged usher yet. Sorry about that. If you would like to help, I can sponsor the package into Debian for you. -- Ludovic Brenta (Debian developer and sponsor of monotone packages). ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of blue sky ideas?
Stephen Leake stephen_le...@stephe-leake.org writes: On the other hand, almost everyone on comp.lang.ada agrees that I'm an outlier when it comes to any computer tool (for example, I use Ada and Emacs unless forced not to :), so my position on things doesn't seem to be worth much these days ... There are two of us :) -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] GPLv3 code in monotone
Stephen Leake stephen_le...@stephe-leake.org writes: Zack Weinberg za...@panix.com writes: On 2011-05-20 4:46 PM, Stephen Leake wrote: GPLv3 was heavily reviewed before it was released, and has been out for almost 4 years. Can you elaborate? I'm sure there are good reasons not to bother going to GPLv3, but I don't understand what you mean by premature. Switching to GPL3 would make us license-incompatible with a large body of code (everything under a copyleft that isn't v3-compatible, in particular, code under v2-only). It would also make us license-compatible with a large body of code (anything that adds restrictions that are okay with v3 but not v2). It is my impression that the former body of code is much larger than the latter, and it is my opinion that we should not switch as long as that remains the case. If everyone adopts this attitude, no one will ever switch to GPLv3. And we would not be using GPLv2+ now; we'd be stuck with GPLv1. +1 Since we have benefited so much from the Gnu packages and the FSF licenses, I think we have a duty to move to GPLv3, since it gives better support for software freedom. +1 I recommend that the relicensing to GPLv2+ that Stephe approved apply to monotone 1.0 but that the next published release of monotone migrate to GPLv3+. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change
On Tue, 10 May 2011 09:09:15 +0200 (CEST), Richard Levitte The word path has been expanded, especially if we speak in URI terms, to something of a structured notation to reach a specific resource within a specific realm. That's exactly the way PATH is used in mtn://HOST/PATH?PATTERN . hendrik This still leaves room for confusion, since (unless I'm hendrik grossly confused) it's not the file name of the data base hendrik that's wanted here. No, it's not the file name of the database, but it's a way to reach it. My main issue, though, is that things are expressed differently in the monotone speak and in usher speak, that's where we have a real possibility for confusion. How would you have it? How about replacing server with URI? That makes it explicit that the string is what the client will use to connect to the server. I also do not like the local moniker; it does not reflect what the thing is. How about: URI mtn://HOST/newpub server-options --confdir /home/levitte/usher.projects/newpub -d /home/levitte/usher.projects/newpub/database.mtn --no-standard-rcfiles --rcfile /home/levitte/usher.projects/newpub/monotonerc --timestamps --ticker=dot ? The presence of the hostname in the URI makes it possible for usher to support virtual hosts, or even to redirect http:// queries to a viewmtn server :) There could be additional variables like: server /usr/bin/mtn directory /home/levitte/usher.projects/newpub such that the server runs in a chroot in the specified directory, with dropped privileges such that it cannot read or write outside that directory. The server variable could allow the sysadmin to run different versions of monotone (e.g. a stable production version and a development version) under the umbrella of a single usher, migrating servers to a new version one by one as the needs arise. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch management
Thomas Keller m...@thomaskeller.biz writes: Now to the question which branches we really want to take care of. Since 0.48 is quite around I think it makes sense to support this a little longer - at least until Debian moves to a newer version - and backport important stuff as needed. Thanks a lot for that. Yes indeed, Debian 6.0 Squeeze will ship with monotone 0.48 and will be supported for at least 2.5 years (i.e. the life cycle of Squeeze plus one year after the release of its successor, Wheezy). It is a bug plus for us to know that you will provide long-term support for this version of monotone. Note however that the Debian maintainers have already done a very good job of backporting critical fixes from the main line, by means of Debian-specific patches; they maintain these patches in the branch org.debian.monotone. Thus, an upstream stable release branch is not absolutely necessary for Debian but it might prove very useful for other distributions. The translation update of course did not break anything for us, but I don't know for example if Debian policies allow i18n updates at all in the lifetime of a package and if this work is actually seen for 0.48 users. (I do think its seen otherwise the original author wouldn't have send the patch probably, but I don't know the rules enough). Translation updates are specifically allowed as part of the deep freeze policy[1] that currently applies to Debian. Richard or Francis, could you please commit a suitable patch as an immediate descendant of t:debian-monotone-0.48-3 (fbfd33230edd751a48e33774dbfb4af434eb0910)? It is OK to use the branch org.debian.monotone.squeeze for that. [1] http://lists.debian.org/debian-devel-announce/2010/11/msg6.html -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Martin Dvorak wrote: I never was fan of the x.99.x/x.9x/etc. version numbering for betas of new major versions. I've been thinking about stable/development version numbering recently (and also in the past) and I think it's better to call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using the target major version but appending a suffix that marks it's not the final release. What do you think? Are there any issues with this scheme for users and/or automatic tools, such as package managers in Linux? Debian supports this using a tilde to separate the target major version and the suffix, e.g. 1.1~alpha5, 1.1~beta3, 2.0~rc2. I don't know about other distros. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 'SelfHostingInfo' on mtn wiki
Hendrik Boom wrote: On http://wiki.monotone.ca/SelfHostingInfo/ it says: $ # Command for monotone =0.48 $ mtn --db=mtn.db clone mtn://monotone.ca/monotone ?net.venge.monotone* \ -b net.venge.monotone monotone but when I try this I get: hend...@april:~/dv/mtn$ mtn --db=mtn.db clone mtn://monotone.ca/monotone ?net.venge.monotone* -b net.venge.monotone monotone Usage: mtn [OPTION...] command [ARG...] [...] That's because of: Wed Sep 3 21:13:18 UTC 2008 0.41 release. Changes - 'mtn clone' now takes a branch argument rather than a branch option which is more what people expect given the fact that mtn push/pull/sync do not use a branch option either. Could someone please add the relevant information for monotone = 0.40 in SelfHostingInfo? For that matter, there should also be an entry for monotone = 0.33, since the clone command appeared in 0.34. And perhaps a note to the effect that monotone 0.26 is no longer supported due to netsync compatibility being broken in 0.26. rant People do not necessarily use the latest and greatest version of anything, for various reasons. One possible reason is that Debian stable releases are supported for one year after the next stable release becomes available; this means the Debian 5.0 Lenny will be supported *at least* until November 2011 (in the unlikely event that Debian 6.0 Squeeze is released this month). There are other long-term-support distributions out there; Red Hat Enterprise Linux for example has a 7-year support policy (!). /rant -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Migration to indefero
I created my account, mostly for the migration of the Savannah tickets to indefero, but I also happen to have push permission on the main monotone.ca database. I need this permission essentially for the org.debian.monotone branch, which I do not see on http://code.mtnserv.thomaskeller.biz . Are there plans to create a new project for this branch, or to add the branch to the main monotone project? Either way is fine for me. -- Ludovic Brenta. pgpdwnbdciRIV.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Migration to indefero
Thomas Keller wrote: Am 27.09.2010 12:32, schrieb Ludovic Brenta: I created my account, mostly for the migration of the Savannah tickets to indefero, but I also happen to have push permission on the main monotone.ca database. I need this permission essentially for the org.debian.monotone branch, which I do not see on http://code.mtnserv.thomaskeller.biz . Are there plans to create a new project for this branch, or to add the branch to the main monotone project? Either way is fine for me. If you need project management capabilities (wiki, bug tracker, etc.) for it, then I can easily set up a new project, otherwise please use the contrib project. I'll add you as member in a few. contrib is fine; the bug tracking system is that of Debian and we already have a dedicated mailing list, monotone-deb...@nongnu.org. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: /etc under version control
Gour D. g...@atmarama.net writes: Hello! For a long time I wanted to keep my /etc under version control, but darcs is one of those DVCS where it is explicitly said it is not safe to do due to lack of support for perms symlinks...So, this is nice opportunity to deploy Monotone... On #monotone I've got info to take a look at 6.1.10 Attribute Handling, but would like to hear some more hints how to proceed in the /etc under mtn project? I've been doing this for several years now, without a problem on my Debian laptop. The only trick, for me, was to ignore some files which are symlinks to files outside /etc (most of these point to binary executables anyway). Here is my /etc/.mtn-ignore: rc.\.d mtab alternatives I have a dedicated database, /var/lib/monotone/etc.mtn-0.46, which is owned by root and only writable by root. I usually use only one branch, org.ludovic-brenta.etc, and switch to another branch when spending time at my parents' home (and using their wifi access). I commit changes made by the package manager directly to that branch. I do not need to keep the pristine configuration files under version control since Debian already local changes nicely. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
Just for the record, I agree with Francis entirely and second his suggestion. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone man page
Stephen Leake stephen_le...@stephe-leake.org writes: The monotone Debian package installs the info file in the standard location; it could also install the man page. Yes, it does; Debian Policy mandates a man page for each executable. The current man page is from one of the first Debian package maintainers; it is now very out of date. It could also install the html version of the manual in a standard location; it doesn't do that at the moment. The man page should give URLs for both the remote and local HTML manuals. The package monotone-doc does install the HTML, PDF, info and plain text versions of the manual in the standard location /usr/share/doc/monotone-doc/*. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] is monotone for me?
Gour g...@gour-nitai.com writes: a) what do you find as the reason for not wider acceptance of monotone? (I know darcs is not too popular as well, but, at least, it is used widely within Haskell community.) Is there something which is, according to the public criticism lacking in monotone or it is simply a fact that it's too different and not named Xit? I think a combination of: - Linus considered monotone and decided to write git instead because monotone was too slow for his use, so lots of people noe believe monotone is slow - Monotone does not serve over HTTP, so hosting is a bit difficult - Monotone is for adults :) The reasons are, in fact, similar for those for not using Haskell :) b) there are some possibilities for hosting darcs repos, but, according to the wiki, there is only one site offering public hosting for monotone. Do I miss some? There is a second one, http://www.ada-france.org/article131.html but only for Ada projects (I'm the admin). c) considering b) it seems practical to think about using one's own hosting for the project, I'm curious about memory requirements on the server (for medium-sized project)? The monotone server currently running on ada-france.org uses 159 MiB of virtual memory. While syncing a second monotone process uses 39 MiB. [...] I know there is tool named Tailor, but I'd like to hear about any experience how it works with monotone? It works well; I use it to nightly replicate a large Subversion repository into monotone. I can provide help if you have specific questions. e) I'll try for myself, but let me ask whether Guitone is capable to replace need for cli for less experienced users? I use the command line and emacs, sorry. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Extended selectors
Timothy Brownawell writes: I have a branch net.venge.monotone.extended-selectors that allows selectors to use graph operations, and be combined with 'or' as well as 'and'. It allows things like for example mtn diff -r 'lca(h:*extended-selectors;h:net.venge.monotone)' -r h:*extended-selectors Great! This has been a personal request of mine for years, see https://savannah.nongnu.org/bugs/?18302 The additional things you can do with selectors are: foo|bar|baz I would prefer another character; the pipe needs quoting in most shells. Maybe ^? 'or' (to go with the foo/bar/baz 'and' we already have) (foo|bar)/(baz|qux) grouping parentheses, directly mixing '/' and '|' is actually forbidden so you can't get confused about what it will do Great; just like in Ada! Thanks a lot for all your hard work. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove
Follow-up Comment #10, bug #17878 (project monotone): What does the fix branch do? Several proposals appeared in this bug report and I'm not sure which one was finally implemented. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17878 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove
Follow-up Comment #6, bug #17878 (project monotone): That seems reasonable. Thinking more about this, disapprove should probably update to the parent revision of the disapproved revision; that would match the expected workflow (i.e. A | B | d fork If you disapprove B (creating d), this probably means you want to go back to A and create the fork revision). If the disapproved revision has no or multiple parents, do nothing and emit a warning. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17878 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #23349] I(right_uncommon_ancestors.find(right_rid) != right_uncommon_ancestors.end())' violated
Update of bug #23349 (project monotone): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #2: I tried to reproduce the problem with Debian monotone 0.45-2 and the problem is no longer there. Closing the bug as fixed. Output of mtn version --full: Running on : Linux 2.6.32-3-amd64 #1 SMP Wed Feb 24 18:07:42 UTC 2010 x86_64 C++ compiler: GNU C++ version 4.3.4 C++ standard library: GNU libstdc++ version 20091102 Boost version : 1_40 SQLite version : 3.6.23.1 (compiled against 3.6.20) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.8 (compiled against 1.8.6) Changes since base revision: format_version 1 new_manifest [a4583b2d0cae8cb6889b8701543aeb4efc7e1554] old_revision [a19f8b2017c81c3c6c8b2bb3247f865f6ed4e5a9] Generated from data cached in the distribution; further changes may have been made. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?23349 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove
Follow-up Comment #4, bug #17878 (project monotone): In the scenario I described, disapprove cannot warn when it creates divergence because it does not create divergence. Indeed, it is commit that later creates the divergence. IIUC, adding a message in the changelog works only if the user does not pass -m comment to commit (which, personally, I do quite often); -m would defeat your helpful message. Therefore, -1 on your proposed solution :) What is wrong with my two proposed solutions? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17878 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Net sync with 0.47 server fails...
J Decker wrote: syncing with 0.47 server results on the client mtn.EXE: warning: protocol error while processing peer hostname: 'received network error: denied 'c64200903a4402fff7dcf6343d0290dfbecb5713' write permission for '*' excluding ''' doing a quick serch for 'monotone sync 0.47' comes up with http://osdir.com/ml/debian-bugs-dist/2010-03/msg06590.html I suppose you mean http://bugs.debian.org/574512 I had to modify my server's monontonerc to return true for get_netsync_read_permitted and get_netsync_write_permitted... otherwise, even though the key is listed as if( identity == u...@host.com ) then return true end it doesn't allow the user read or write permission. Your problem seems unrelated to the Debian bug you mentioned. It also seems unknown to the Savannah bug tracking system. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #29310] Currently impossible to escape from multi-parent workspace
Follow-up Comment #1, bug #29310 (project monotone): I've been slightly annoyed by that too; my response was to edit the file _MTN/revision by hand. Hope this helps. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?29310 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Thomas Moschny wrote: Hi! Just to let you know, that the new home of ViewMTN is here: http://viewmtn.1erlei.de/ . There's also a live ViewMTN instance at http://mtn-view.1erlei.de/ carrying the nvm* branches as well as some random other branches that are mtn-related. Feel free to send me comments or hints regarding ViewMTN or the website, or if you like to see some other branches served there. Thanks for taking over this maintenance! I have been using viewmtn on http://www.ada-france.org:8081 for several years now but do not have the time or skills to do upstream maintenance as well. Note that the new home of the project is in fact a Trac instance, so the preferred way of communicating is to open a ticket there. I reported a bug here in March. I'd like to open a ticket but cannot log in and I didn't find out how to create a new user account for me (if you want/have to create one manually, use lbrenta as the user name). The bug report is here: http://lists.gnu.org/archive/html/monotone-devel/2009-03/msg00108.html -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Thomas Moschny writes: Ludovic Brenta wrote: I reported a bug here in March. I'd like to open a ticket but cannot log in and I didn't find out how to create a new user account for me Thanks for the hint. You should now be able to create a ticket without having an account. (Hopefully the spam filter works reasonably well ;) I could create it all right (http://viewmtn.1erlei.de/ticket/1) but I cannot see it; the URL contains only the error message: Unsupported version control system svn: Can't find an appropriate component, maybe the corresponding plugin was not enabled? PS. This is the first time I create a bug report with number 1 :) -- Ludovic Brenta. pgpW8NER2QOyG.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] .mtn-ignore ignored?
Hello, It seems my regexps in .mtn-ignore no longer works. When I call mtn ls ignored, the resulting list is always empty. When I do mtn add -R ., it add all files including the ones I want to ignore, and that match the regexps. I think this is a regression since 0.36 or so; I know for a fact that these same regexps used to work. Do recent versions of monotone still support .mtn-ignore, as the documentation says? I currently run: monotone 0.44 (base revision: b0498387aa9570fb7bd97845de14f63a88d8658a) Running on : Linux 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 C++ compiler: GNU C++ version 4.3.3 C++ standard library: GNU libstdc++ version 20090714 Boost version : 1_38 SQLite version : 3.6.18 (compiled against 3.6.16) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.6 (compiled against 1.8.4) Changes since base revision: format_version 1 new_manifest [e4fc965aec46ce8b371e818de6092168e1b6f52f] old_revision [7a4832143b3146ca89f5cb91e0e571d05e29d4b9] Generated from data cached in the distribution; further changes may have been made. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] .mtn-ignore ignored?
Timothy Brownawell writes: Ludovic Brenta wrote: Hello, It seems my regexps in .mtn-ignore no longer works. When I call mtn ls ignored, the resulting list is always empty. When I do mtn add -R ., it add all files including the ones I want to ignore, and that match the regexps. I think this is a regression since 0.36 or so; I know for a fact that these same regexps used to work. Do recent versions of monotone still support .mtn-ignore, as the documentation says? Yes, for example the .mtn-ignore in net.venge.monotone seems to work fine. 0.37 did switch from Boost::regex to PCRE, but NEWS says this shouldn't have broken anything. Do you have examples of the patterns and the files they're failing to match? $ cat .mtn-ignore debian/files debian/gnat $ mtn ls ignored $ mtn ls debian/files debian/gnat debian/files debian/gnat: DEBIAN usr $ mtn ls known .mtn-ignore debian debian/changelog debian/compat debian/control debian/copyright debian/rules debian/source.lintian-overrides $ mtn add debian/files # should be ignored mtn: adding debian/files to workspace manifest I sincerely hope I'm doing something wrong... I tried the following regular expressions, all with the same result: debian/files ^debian/files$ /debian/files ^\./debian/files$ ^/debian/files$ (The last three do not match the output of mtn ls unknown so I don't expect them to work; but I do expect the first two to work.) -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] .mtn-ignore ignored?
Timothy Brownawell tbrow...@prjek.net writes: They should work, and they *do* work here. So if you haven't overridden the ignore_file() hook and this is in the workspace root directory, I'm not sure what could be going on. Heh. Thanks, that reminded me that I overrode ignore_file() back in 2006... I copied and pasted the then-default version which read .mt-ignore instead of .mtn-ignore. (if you're curious: I didn't want to ignore *.a files because GCC sources contain files with this extension, containing Ada test cases instead of static libraries). -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Server broken
Richard Levitte levi...@gmail.com writes: What I'll do next is to move the server home within the week that comes [...], check things through, copy what can be copied to the spare disk, take the rest from backups (the backup is good), move disks around and take it back to co-location, then cross my fingers. Since this server is mission-critical (its missions being to serve monotone databases and your email), how about migrating to serious server hardware with RAID storage? Thanks to virtual machines, this can be as inexpensive as a dedicated server, e.g. http://wiki.openvz.org/Hosting_providers http://linux-vserver.org/VServer_Hosting -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Timothy Brownawell tbrow...@prjek.net writes: On Tue, 2009-08-25 at 20:24 -0500, Timothy Brownawell wrote: I'm now thinking we can make the about-to-be-released clients work with current-version servers. If they see an earlier-version hello from the server, they just need to store that in the session and use it for all packets sent. The only actual difference would be the cert data packets, and which hashes to use during cert refinement (would have to store both old and new hashes in the db). I'll see if I can code this up later this week or this weekend. In the future, the server would also have to recognize earlier versions in the auth/anonymous packets and adjust itself accordingly (easy, since server/client use almost exactly the same code). This is done. New-version servers can also talk to old-version clients, they now start with usher_cmd (which the client ignores the version of) instead of start_cmd. So we now have full protocol version negotiation between 0.44 (and earlier) and 0.45dev (and future). Wow, I'm really impressed. The monotone community is really amazing and I'm proud to be part of it (as the sponsor of the package in Debian and as a strong supporter, not as a developer). However I'd like to better understand how old and new monotones are compatible (or incompatible) WRT the new key hashes. Could you explain what happens when: - a new client sends certs to an old server? - an old client (belonging to another developer) gets those certs from the server ? i.e. how does the old monotone see the certs and how does it interpret them? If there are any user-visible effects, I think they should be in the user's manual. ...do we want to call it 1.0 due to caring about compatibility now? *ducks* If the compatibility is good, there is no need for a major version number bump and no need for you to duck. On the contrary you should stand proudly and let everyone else bow in reverence :) -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Timothy Brownawell tbrow...@prjek.net writes: For certs signed by key f...@bar.com (abcd...): * If there is only one key with that name, there are no user-visible effects. * If there is also a key f...@bar.com (1234...): * If the new-version peer has both keys, there is no user-visible effect when it receives certs. * If the old-version peer only has 1234... and the new-version peer doesn't have abcd..., then the new-version peer will drop the incoming certs (because the old peer can't send it the correct key, so it can't correctly identify the key hash to attach the certs to) and print a warning. Fair enough (1). * When the old-version peer receives certs signed by the key it doesn't have, the new-version peer will try to send that key and the old-version peer will drop the connection with received duplicate key. Fair enough (2). Hmm. If you migrate a database containing key f...@bar.com (1234...) and certs signed by key f...@bar.com (abcd...), the upgrade logic will attach them to that (wrong) key because it assumes your db is consistent. So we need a command that will try to reassign any invalid certs to the correct key, and maybe optionally delete them if it doesn't have that key (so you'll be able to get a good copy, with the key, during your next pull). We probably also want to drop certs with bad signatures (ie, attached to the wrong key) during netsync, so they don't spread. But a database that needs upgrading is necessarily = 0.44 and therefore cannot possibly contain two keys with the sane name, can it? And per (2) it cannot contain certs signed by the key it doesn't have, can it? So your scenario cannot happen, can it? So all is well... ? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Selon Stephen Leake stephen_le...@stephe-leake.org: Thomas Keller m...@thomaskeller.biz writes: So I think now that this change is in nvm, we should start dealing with that. I see basically three options: a) We don't care at all about netsync breakage. After all there *is* a reason why we have no 1 as major version number... If you find this unfair towards bigger projects, ok, then lets make a 0.44.x branch and split up the development here. If people want the new features, they have to upgrade, if not, we promise that we fix critical bugs for the 0.44.x line for at least the additional time we see projects using the old client. Since this is a rather small community and monotone hasn't seen many critical bugs in its history, I think this is managable. This is a good fall back plan. I second this; that's basically what I asked for in my first email, with the only difference that 0.44.x should be 0.x and 0.45 should be 1.0. This makes the incompatibility prominent and easy to warn about and to diagnose. This is in addition to the benefit I already described with multiple versions in a distribution. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Richard Levitte rich...@levitte.org writes: stephen_leake I agree; we should hold the next monotone release until stephen_leake netsync version negotiation is supported. So now, all we gotta do is hack that as good and fast as we can? Cheers, Richard ( it won't help current clients anyway, will it? ) Yes, it would; a client built from today's n.v.m head cannot speak to a server running on a long-term-support operating system such as Debian stable. Not can it speak to any other client a week old, for that matter. This is acceptable for individualls or small teams but not for the scenario where a central server is involved. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] netsync flag day justifies bumping version number to 1.0
Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. This would allow us, maintainers of monotone in Debian, to provide two versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), or monotone1 and monotone. This would allow people to have both versions installed at the same time, without a clash. I think this would be desirable because Debian 5.0 Lenny contains version 0.40, runs on many servers including www.ada-france.org, and will remain in service for at least another two years. Thus the transition period for the netsync change cannot be shorter than that. In fact, I would suggest a policy whereby the major version number changes whenever netsync changes; if this policy had been in place since the beginning of monotone development the next version would be 3.0 or 4.0, I believe, -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] commit and sink in same transaction
Zack Weinberg za...@panix.com writes: 2009/3/23 serg sergeybely...@yandex.ru: Hi. Can I synchronize (serve, pull, ...) the repository and do commit changes in same transaction without data loss through software API? Thanks. No, but the question as phrased makes no sense in monotone's framework, so I suspect you're thinking about the task the wrong way. If you explain your larger goals we may be able to tell you how to do what you really want. I suspect what the OP wants is to automatically push to a remote database every commit on the local database. This looks possible with the note_commit hook; see http://monotone.ca/docs/Hooks.html#Hooks (but I don't know enough of Lua or hooks to be sure hooks can call back into monotone to, e.g., sync). -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] File descriptor leak in ViewMTN
Hello The ViewMTN server running on www.ada-france.org (revision ff6f92608b076dabc1da2f37b4aa326f47a8a7eb) leaks file descriptors and eventually stops running. The log file ends with the following stack trace: xxx.xxx.xxx.xxx:y - - [15/Mar/2009 01:03:45] HTTP/1.1 GET /branch/changes/org.debian.libxmlada2/from/10/to/20 - 500 Internal Server Error http://xxx.xxx.xxx.xxx:/ Traceback (most recent call last): File /var/lib/monotone/net.angrygoats.viewmtn/viewmtn.py, line 173, in ? File /var/lib/monotone/net.angrygoats.viewmtn/web/request.py, line 153, in run File /var/lib/monotone/net.angrygoats.viewmtn/web/wsgi.py, line 54, in runwsgi File /var/lib/monotone/net.angrygoats.viewmtn/web/httpserver.py, line 222, in runsimple File /var/lib/monotone/net.angrygoats.viewmtn/web/wsgiserver/__init__.py, line 869, in start File /var/lib/monotone/net.angrygoats.viewmtn/web/wsgiserver/__init__.py, line 896, in tick File socket.py, line 161, in accept socket.error: (24, 'Too many open files') But the process is still running. When I do lsof -p $pid_of_viewmtn I see hundreds of: COMMAND PID USER FD TYPE DEVICESIZE NODE NAME python 20746 monotone5u IPv4 36327705 TCP sd-12156:tproxy-crawl-66-249-71-208.googlebot.com:61384 (CLOSE_WAIT) python 20746 monotone6u IPv4 36328012 TCP sd-12156:tproxy-llf520097.crawl.yahoo.net:44377 (CLOSE_WAIT) python 20746 monotone7u IPv4 36328029 TCP sd-12156:tproxy-llf520097.crawl.yahoo.net:54333 (CLOSE_WAIT) python 20746 monotone8u IPv4 36328034 TCP sd-12156:tproxy-llf520097.crawl.yahoo.net:57328 (CLOSE_WAIT) python 20746 monotone9u IPv4 36328375 TCP sd-12156:tproxy-llf520097.crawl.yahoo.net:60411 (CLOSE_WAIT) python 20746 monotone 10u IPv4 36328397 TCP sd-12156:tproxy-llf520097.crawl.yahoo.net:34835 (CLOSE_WAIT) python 20746 monotone 11u IPv4 36328398 TCP sd-12156:tproxy-crawl-66-249-71-208.googlebot.com:43420 (CLOSE_WAIT) python 20746 monotone 12u IPv4 36328410 TCP sd-12156:tproxy-llf520097.crawl.yahoo.net:45122 (CLOSE_WAIT) Right now there are 885 such open sockets, most of which are from web spiders. The process has reached its limit of 1024 open file descriptors and is unresponsive (the other file descriptors include sockets and established connections). I was briefly tempted to write a couple of firewall rules but I realize that this is futile; I cannot reliably distinguish between a spider and a human connection. According to [1], it seems like a bug whereby ViewMTN fails to actually close connections after being notified that the client wants to close the connection. [1] http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html Thoughts? -- Ludovic Brenta. pgpLqAybSqoLB.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #25859] disapprove does not resurrect files properly
I just filed a new bug: http://savannah.nongnu.org/bugs/?25859 I still use 0.40 and I would like to know: - whether Stephe Leake's file suturing work solves this bug - whether it is merged - which release of monotone contains or will contain it Thanks -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] MonotoneOnDebian
Zack Weinberg za...@panix.com writes: On Wed, Feb 25, 2009 at 6:12 PM, hend...@topoi.pooq.com wrote: In http://monotone.ca/wiki/MonotoneOnDebian/ it says, Monotone packages can currently be found in the Debian repositories. Monotone changes very rapidly and versions in sarge and etch may be slightly dated. It is recommend that you use the monotone package from the monotone website or the version that is in sid/unstable which is generally kept up to date. But going to the monotone website, I find no .deb packages for etch. There are packages for Suse, but that's not the same. Hm, perhaps that should be reworded. The .deb on the website is generally built against sid, and I doubt it will work on etch myself. We generally haven't bothered doing backports but if you grab the source package from sid (0.40-7) it should build fine against etch's libraries. I agree that the paragraph should be removed. It is no longer true that monotone changes very rapidly; in fact, it has an amazing track record of backwards compatibility (at the netsync level) since 0.26. The changes in database schema are more frequent but not generally a problem since migration is painless. The user interface has remained clear, simple and consistent all along despite the new features. That's one of the reasons I like monotone so much and I'm happy using whatever version of monotone is in Debian (currently 0.40-7), even if it is not the latest. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN shows empty list of branches; error in log
Timothy Brownawell tbrow...@prjek.net writes: NEWS says that mtn suspend and the --ignore-suspend-certs option were added in 0.41. OK, then I suggest that the INSTALL document mention that viewmtn requires monotone = 0.41. Currently it says: Monotone: http://monotone.ca/ A version which is descended from [62961c1dc..] is required. This is post-0.30. Thanks to your reply, I have patched viemtn minimally so it doesn't pass --ignore-suspend-certs to monotone. This way I have been able to restore the ViewMTN service on www.ada-france.org:8081. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] FOSDEM 2009
If anyone on this list plans to attend FOSDEM 2009, I'll be in the Ada developers' room which I helped organize [1]. I'll be happy to meet for a chat, beer and GPG key signing. Please get in touch with me if you're interested. Also, if several people plan to attend FOSDEM, it might be a good idea to set up a mini-summit there? -- Ludovic Brenta. pgpZ1PXQgP9A7.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera writes: Ethan Blanton wrote: Then, to connect to the server, run something like the following on your workstation: ssh -L4691:localhost:4691 server Could you clarify this command? My reading of it is: ssh -L4691:localhost:4691 [EMAIL PROTECTED] Which would require me to have SSH login (daniel). What am I missing? You are correct but the [EMAIL PROTECTED] account may be unprivileged (running a restricted shell) and shared with other developers. You might as well call it after the project the developers work on, e.g. [EMAIL PROTECTED] The monotone server itself, and the database, belong to and run as a different user, e.g. [EMAIL PROTECTED] I run a public monotone server on www.ada-france.org; see http://www.ada-france.org/article131.html for explanations. The security model is simple: everyone has read access, and only a few trusted developers have write access to the entire database (they can create branches at will). Because this is a netsync server running as a monotone user that has /bin/false as its shell, only sysadmins with root access to the machine can delete from this database. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Security and Permissions
Daniel Carrera writes: Hello, I believe that Monotone can be configured so that some users are not able to read or write certain parts of the source tree. But I can't figure out where this is explained. I can't find it in the docs. Could someone point me to the right place? The security model is actually quite crude as write permissions are database-wide. Read permissions can be per-branch within a database; see Network Service Revisited in the doc. To complement the security model, there is also a trust model. You can set up a per-user filter in your ~/.monotonerc that will hide all revisions you don't trust. See Trust Evaluation Hooks in the manual. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Selon Thomas Keller: Ludovic Brenta schrieb: Or teach db kill_rev_locally to only change the workspace's parent revision without changing anything to the workspace? This is what I meant with workspace merge - of course the parent of the current workspace no longer exists if it is killed, so old_revision gets rewritten to the parent of the killed revision. Then, the killed revision's changeset is merged (plucked?) into this altered workspace. That last step is unnecessary because the workspace already contains the changes in the killed revision. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Selon Daniel Carrera [EMAIL PROTECTED]: Daniel Carrera wrote: So I am clear, the entire command is mtn db_kill_rev_locally and that's it? If we convinced the devs to make mtn uncommit an alias to mtn db_kill_rev_locally would that cover my use case? I just tried this on a sandbox branch and it doesn't work that well. In particular, it fails if there are any uncommitted changes: % mtn status Current branch: foo.sandbox.branch Changes against parent dcfbf59823cf21e292b60ba8f8463f65ea383597 addedfoo % mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597 mtn: misuse: Cannot kill revision dcfbf59823cf21e292b60ba8f8463f65ea383597, because it would leave the current workspace in an invalid state, from which monotone cannot recover automatically since the workspace contains uncommitted changes. Consider updating your workspace to another revision first, before you try to kill this revision again. This is not good. Suppose I have edited files Foo1, Foo2 and Bar. I run mtn commit Foo1 because I forgot about Foo2. So I decide I want to undo that last commit so I can run mtn commit Foo1 Foo2 which is what I wanted initially. Monotone won't let me do it because file Bar has changes. That's where my trick comes in: manually edit _MTN/revision without changing anything else in your workspace, then kill the head revision. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Selon Thomas Keller: Ludovic Brenta schrieb: Selon Thomas Keller: Ludovic Brenta schrieb: Or teach db kill_rev_locally to only change the workspace's parent revision without changing anything to the workspace? This is what I meant with workspace merge - of course the parent of the current workspace no longer exists if it is killed, so old_revision gets rewritten to the parent of the killed revision. Then, the killed revision's changeset is merged (plucked?) into this altered workspace. That last step is unnecessary because the workspace already contains the changes in the killed revision. Right, wrong wording: its not merged into the altered workspace, but into the workspace' _MTN/revision (after all f.e. a previously added file has to be marked as added again there). I don't see why; the altered _MTN/revision still contains the new manifest ID that has the new, moved or deleted files. Or am I missing something? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Selon Daniel Carrera [EMAIL PROTECTED]: Hi Thomas. I tried this and it looks like the diff/patch step is unnecessary - and indeed, if you run patch you actually break the workspace. It appears that 'mtn revert .' is enough to solve the problem with kill_rev_locally. Only partially; in your test you lost the fact that you added file asdf: % mtn add asdf mtn: adding asdf to workspace manifest [...] % mtn revert . [...] % mtn db kill_rev_locally 3be3ed81bd01509d0c1e2db46e987b1040bbc222 mtn: applying changes from 3be3ed81bd01509d0c1e2db46e987b1040bbc222 on the current workspace % mtn status Current branch: foo.sandbox.branch Changes against parent 9f79e6063616d8fb85cad56253e39c2c49927899 patched foo Now you have to mtn add the new file again. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Selon Daniel Carrera: Ludovic Brenta wrote: Or teach db kill_rev_locally to only change the workspace's parent revision without changing anything to the workspace? Or make a command mtn rollback that is equivalent to kill_rev_locally without changing the workspace. It should be simple enough. Step 1: Edit _MTN/revision to point to the previous revision. Step 2: Run kill_rev_locally on the last revision. I would prefer a single-purpose command, mtn rebase -r rev, that only rewrites the old_revision field in _MTN/revision. Then, the user can either kill_rev_locally h:, disapprove h:, or simply commit to create a divergence if that's what they want. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Hooks
Selon Daniel Carrera: Is it possible to write a hook that implements Ludovic's solution to the undo a commit problem? : I'm not very comfortable with lua either and my first move was to write a shell script along the lines of: #!/bin/sh head=$(mtn automate get_base_workspace_revision) parent=$(mtn automate select p:$head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision but this approach fails as soon as the head has more than one parent. That's why, until now, I stuck to the manual way. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Please add me to the monotone group on savannah.nongnu.org
I notice that bug #18317 has been resolved since 0.37 with nobody taking the time to close it. Someone, please add me to the group so I can at least do basic bug triaging when I have a couple of minutes. I'm sure other bugs could be closed in a similar way. I already have write permission on the monotone database BTW. Thanks. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Selon Daniel Carrera [EMAIL PROTECTED]: Ludovic Brenta wrote: That's where my trick comes in: manually edit _MTN/revision without changing anything else in your workspace, then kill the head revision. Ok. So let's see that process again: ## Current revision: aa $ mtn commit ## Current revision: bb ## Ooops, wrong commit. $ vi _MTN/revisions ## Edit this file. $ mtn db kill_rev_locally bb Did I get it right? Yes, that's right. Now, how do I edit _MTN/revisions? It appears to contain 2-3 hashes: [...] When I run mtn status I see the same hash as old_revision. So in my example above I would set old_revision to aa. But what do I do with the other hashes? Change the old_revision and leave the others alone. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Selon Thomas Keller [EMAIL PROTECTED]: I'd do it safely without messing around with _MTN/revision and move the current changes aside to re-apply them later on: $ mtn diff current_changes.txt $ mtn revert . $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597 $ patch -p0 current_changes.txt The problem with this safe approach is that it is unsafe in the presence of new, moved or deleted files. A new but uncommitted file will appear as a hunk in the diff, it will survive the mtn revert ., and applying the diff will double its length. A moved file will actually not appear in the diff at all, except as a comment; reapplying the diff will lose that change. A deleted file may appear as a hunk in the diff (I'm not sure anymore; it may also appear only as a comment) in which case reapplying the diff will not delete the file, only make it empty. Of course we could teack kill_rev_locally also to accept workspace changes and essentially do a workspace merge for these cases, but I'm not sure if there is really a use case for this which is worth to mess with that. Or teach db kill_rev_locally to only change the workspace's parent revision without changing anything to the workspace? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Daniel Carrera writes: mtn rebase rev OK, that's an improvement on my proposal. The command db kill_rev_locally is long so I don't like it. What would be the consequences of a divergence? Is it ok if I simply run mtn rebase and then go on merrily on my way making my other branches? If so, then I would be entirely happy with rebase. After mtn rebase p:, there are two ways you could create a divergence: $ mtn commit creates a second head in the same branch; later on, mtn checkout, mtn update and other commands will complain that there are two heads and require you to select a head manually. You can resolve that either with mtn merge, mtn suspend or mtn disapprove; it's up to you. This is sometimes called light-weight branching; it is appropriate for short-lived divergences that you intend to resolve at one point in the future. The second way is: $ mtn commit -b new_branch The divergence is then permanent; you now have two branches with one head each; monotone will not complain about that. You can still merge whenever you want with mtn propagate. This is sometimes called heavy-weight branching and is for intentional divergences that you think should live for a while (e.g. stable/maintenance vs. unstable/development). Note that heavy-weight is not that heavy; the only difference is the value of the branch cert. So heavy-weight does not consume any additional space in the database compared to light-weight; but it does consume from the branch namespace. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks
Daniel Carrera writes: Ludovic Brenta wrote: I'm not very comfortable with lua either and my first move was to write a shell script along the lines of: #!/bin/sh head=$(mtn automate get_base_workspace_revision) parent=$(mtn automate select p:$head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision but this approach fails as soon as the head has more than one parent. That's why, until now, I stuck to the manual way. How about this?: count=$(mtn automate parents $head|wc -l|sed 's/ //g') if [ $count != 1 ]; then echo Cannot undo. More than one parent. exit fi parents=$(mtn automate parents $head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision Looks reasonable. Note though that I wrote my proposal directly in the mail and didn't test it. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: ## Oops, I made a mistake. $ mtn log|grep Ancestor|head -n 1 | Ancestor: 4b4069fffd06d8f4c5981314d99838bda9a9b75a $ mtn rebase 4b4069fffd06d8f4c5981314d99838bda9a9b75a Easier: $ mtn rebase p: $ mtn disapprove 1e129601c2cd983fc6c73053cc13544ac36cc229 $ mtn disapprove h: It's not as simple as mtn undo but it's good enough. Yes. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: Ludovic Brenta wrote: Easier: $ mtn rebase p: $ mtn disapprove 1e129601c2cd983fc6c73053cc13544ac36cc229 $ mtn disapprove h: Are p: and h: aliases for parent and head? That *is* easier. Yes. See the chapter Selectors in the monotone manual. mtn rebase p: mtn disapprove h: Very nice. Now, so that I'm clear, what exactly is h:/head? If you rebase, does that change the head? No, it only changes the revision on which the current workspace is based. Other workspaces are unaffected. The database is unaffected. If not, then what happens when a branch has two heads? What would h: mean in that case? In that case, monotone complains and bails out; you have to select one of the heads unambiguously. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Bruce Stephens writes: Daniel Carrera writes: [...] So Monotone is expecting me to figure out which files it is not tracking and remove those files before it'll update the working directory? Yes, when the update is trying to remove a directory containing such files. This is easy to do in a workspace: rm -f $(mtn ls unknown) -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: Daniel Carrera wrote: So Monotone is expecting me to figure out which files it is not tracking and remove those files before it'll update the working directory? I can't have files or directories that monotone does not keep track of? The include/php directory has an external php library. No sense in having that in my monotone database. Indeed, that seems to have been the case. After making a backup of my certification directory I removed all the files that were not in Monotone. That includes the _darcs directory, hidden files, a library, test files, a TODO list, etc. Then I ran 'mtn update' and Monotone deleted everything. It deleted all the files and directories under the certification directory. It's ok because I had a backup, but it's not what I was hoping monotone would do. I'm not happy with what Monotone did. If I undo a commit, I don't want Monotone to delete or modify my files. If I wanted that I would have told it to revert. What I want is that Monotone remove that action from the database and then behave as if the commit had never happened. I don't want it to mess with my files unless I say 'revert'. I have a workaround that I used many times already. $ mtn checkout -b some_branch $ edit at will $ mtn checkin # Oops, I made a mistake and I want to take that revison out $ mtn log --last=1 Copy the parent revision $ vi _MTN/revision Replace the current revision with its parent $ mtn db kill_rev_locally h:some_branch And I'm happy. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: Ludovic Brenta wrote: This is easy to do in a workspace: rm -f $(mtn ls unknown) It would be even better if I didn't have to delete these files. Just because Monotone is not tracking them doesn't mean that they are not useful. My TODO list, a library, a quick test file, etc. Those are all legitimate reasons to have files that are not tracked. Yes indeed; that's why monotone will not delete these unknown files under any circumstances. The problem you had was that mtn update needed to replace unknown files with known files; monotone preferred to bail out rather than overwrite the unknown files that were in the way. Over-all I am concerned about the process of un-doing a commit. What I want is a functional equivalent of Monotone acting as if I had not done the commit yet. I don't want it to nuke my files or revert my changes. To achieve this, revert your workspace to the previous revision first, then mtn db kill_rev_locally the offending (head) revision. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone vs Mercurial vs Git
Daniel Carrera writes: Hello, Does anyone know of a web page that compares Monotone, Mercurial and/or Git? I'm not looking for any particular piece of information, I'm just curious. My needs are simple and I'm sure that any of these tools would work for me. My comparison is probably outdated but still available: http://www.ada-france.org/debian/distributed-version-control-systems.html -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz packages for Ubuntu
Ulf Ochsenfahrt [EMAIL PROTECTED] writes: Hi everyone! The old monotone-viz package (which was 0.15 still) didn't work with my new monotone package (0.41), so I've uploaded new monotone-viz packages to my personal package area: https://launchpad.net/~ulf-ofahrt/+archive Why did you do that when the new version is already in Debian? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller writes: So please check NEWS if it contains a note of something you may have done to trunk since 0.40 Speaking of NEWS, it appears that the introduction of suspension certs is documented nowhere in it. I don't even remember what version that was. Could someone please add the appropriate entry, even if that means rewriting history? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: ping Ludovic Brenta
Zack Weinberg writes: I sent you more corrections to the Debian package a few weeks ago and haven't heard anything - do you have time to continue sponsoring the package? Probably next weekend. Did you ping me earlier? I think I missed that. Sorry. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Selon Markus Schiltknecht [EMAIL PROTECTED]: (A challenge for the file resurrection UI: what should mtn do, if the user then wants to resurrect file foo from the merged revision? There are two node ids which were named foo.) It seems to me that, if the node ids were content hashes, it would solve a lot of problems. For one thing, creating two identical files would yield the same node id. For another, creating two different files with the same name on different branches would become a simple content conflict. In the specific case you mention, it would be possible to distinguish between the two foos and select which one to resurrect. Of course I may be completely off-base. Still, I'm very interested in this discussion because I'm having problems with non-content conflicts in the following real-life scenario. I have a database where I replicate, via tailor, a Subversion repository in a vendor branch. In the same database I have my development branch where I do all my work. Occasionally, I add a file in my development branch. In order to propagate changes to the upstream Subversion repo, I apply patches and commit manually in Subversion, e.g. $ mtn diff -r h:vendor -r h:development /tmp/f.diff $ svn checkout svm+ssh://svn.upstream.org/trunk $ cd trunk $ patch -p0 /tmp/f.diff $ svn add foo $ svn commit -m merge from development branch The problem takes place when tailor next updates the vendor branch in the monotone database. At that point, the file foo appears to have been created independently in both branches, so I get non-content conflicts. The way I resolve them is clunky: $ cd ~src/tailor/vendor # this is the monotone checkout that tailor maintains $ mtn rm foo $ mtn propagate development vendor $ mtn update In essence I'm mucking around behind tailor's back. Do you guys think there is a better way, or that using content hashes as node ids would help solve the problem? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Selon Stephen Leake [EMAIL PROTECTED]: Ludovic Brenta [EMAIL PROTECTED] writes: [snip] Occasionally, I add a file in my development branch. In order to propagate changes to the upstream Subversion repo, I apply patches and commit manually in Subversion, e.g. $ mtn diff -r h:vendor -r h:development /tmp/f.diff $ svn checkout svm+ssh://svn.upstream.org/trunk $ cd trunk $ patch -p0 /tmp/f.diff $ svn add foo $ svn commit -m merge from development branch I gather that tailor only provides a one-way link between the svn and mtn repositories? Otherwise you could use tailor to push the new file to svn. You are correct; I use tailor in only one direction. However, even if I would use tailor in the other direction, the problem would remain. Tailor would do no more than rsync the Subversion working space; svn add $(new_files); svn commit. Right. I'm looking for a better way to solve this. I really appreciate that you're taking the time to do this. Such a feature would be very valuable to me. I've proposed a rather elaborate method using the output of 'automate show_conflicts', editing the resulting file, and commiting with 'merge --resolve_conflicts'. For the case where there is only one conflict, or all the conflicts can be resolved in the same way, we could have a shortcut: 'merge --resolve_conflict=resolve_content_ws' Hmm. I guess in your case, since you are doing 'propagate', that would really have to be: 'propagate development vendor --resolve_conflict=resolve_content_ws' Although then ws is ambiguous; it could be either development or vendor. Sigh. Not really. In my case, ideally I should only propagate one way (from vendor to development). So, when propagating from vendor to development, all I really need is a way to resolve all non-content conflicts by ignoring the changes made in the vendor branch. For content merges, emacs allows to use default-A or default-B. If the same was available for non-content conflicts I would be happy. So maybe some variant of 'explicit_merge'. I tried merge_into_workspace and that wasn't entirely satisfactory. I ended up with the result I wanted, but at the cost of really ugly hacks like mtn cat -r some_previous_revision foo foo; mtn add foo. In essence I'm mucking around behind tailor's back. Yes. So the other solution is to make tailor provide a two-way link between svn and mtn. Like I said, it's not clear to me that that would solve anything. Plus, I want to write into the upstream repository manually rather than automatically. Thanks for your help on non-content merges! -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Selon Ludovic Brenta [EMAIL PROTECTED]: For content merges, emacs allows to use default-A or default-B. If the same was available for non-content conflicts I would be happy. To follow up on that, I think this would involve two steps: (1) suturing the two like-named files into one, (2) resolving the ensuing content conflict as usual. In my case, the two files have the same content, but that may not be true in the general case (i.e. if there are some intervening revisions on either branch). For this resolution, I would almost always use emacs' default-A to choose the file contents from development branch when resolving the conflict. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] how do I list what the last changes were?
J Decker [EMAIL PROTECTED] writes: How do I get the list of branches ordered by most recent commit? I got 4 revisions, but I dunno which branch they apply to. I had the same need and resorted to SQL queries: http://www.ada-france.org:8081/revision/file/1f43556b0e35674ae8c1536c7dfcde5062b205f7/what-branches -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
[EMAIL PROTECTED] writes: I've got ~1100 branches with ~100k revisions, ~780k of files, with 20GiB of databases spread out over 2 clusters of 3 machines each. Oh please, give us some numbers on http://venge.net/monotone/wiki/ProjectsUsingMonotone ! -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
Markus Schiltknecht writes: The prefix_matching_constraint() function prepares an WHERE clause, which imitates the sqlite'ism named 'GLOB'. Instead of using a clause like WHERE id GLOB 'deadbe*' It now prepares a where clause more similar to: WHERE id = 'deadbe' AND id = 'deadbf' Sorry to interrupt but in standard SQL there is WHERE id LIKE 'deadbe%' and I happen to use it occasionally on the command line. I'm worried that that won't be possible anymore after the unhexification. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Bug#455646: [Monotone-debian] Bug#455646: FTBFS with GCC 4.3: missing #includes
Zack Weinberg writes: 2) sqlite/vdbeaux.c:2212: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1746 GCC bug. Should be reproducible with the official Debian sqlite package. I do not have time to file a GCC bug report. There already is one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113 -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] FOSDEM
Markus Schiltknecht [EMAIL PROTECTED] writes: Hi, we've also thought about a DevRoom at FOSDEM. Up until now, I only know that Ludovic Brenta wants to attend FOSDEM, Lapo showed some interest and I myself am still undecided if I want to go to Brussels. If nobody else speaks up, I don't think that justifies a DevRoom there. OK. Besides, their wiki [1] indicates that we are already too late to get a DevRoom... No, that applies to last year's FOSDEM: the page was last edited in Feb 2007. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] FOSDEM
Markus Schiltknecht [EMAIL PROTECTED] writes: Hi, Ludovic Brenta wrote: No, that applies to last year's FOSDEM: the page was last edited in Feb 2007. Oops.. sorry. Hm.. their website is really confusing! Any idea about the DevRoom reservation deadline? Regards Markus Like I said initially, historically it's been early october but they are confused about that themselves this year. Better ask now. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] kibi!
Richard Levitte [EMAIL PROTECTED] writes: njs (Why are we talking about this on monotone-devel?) Beats me, I'm just responding to what is said here. Perhaps because Monotone reports byte counts in k, M and G when the locale is unset or English? I do note that the Italian locale says Ki, Mi and Gi. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
Markus Schiltknecht writes: Hi, Nathaniel Smith wrote: If anything, it's probably on the late side to be organizing for January/February, so people probably would want to get on it quick... Yeah, better late than never ;-) Besides, are there any good reasons that it must be Jan/Feb? We could still do in in March or even April, no? It is not too late to ask for a developers' room at FOSDEM in Brussels (23-24 Feb 2008). See http://fosdem.org. Since I live in Brussels, I will definitely attend and can accommodate one person at no charge. I'm also trying to set up an Ada developers' room with several interesting speeches. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Summit 2008
Lapo Luchini [EMAIL PROTECTED] writes: Markus Schiltknecht wrote: IMO, for FOSDEM it seems to make more sense to have a more user focused event. Or presentations and talks or whatever. Or -well- we could have a longer Summit *AND ALSO* some of us (as subset of the European ones, I'd guess) go to FOSDEM as well ;-) Yes, or we could use FOSDEM for users plus the rest of the week for developers. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
Markus Schiltknecht writes: Hi, Ludovic Brenta wrote: It is not too late to ask for a developers' room at FOSDEM in Brussels (23-24 Feb 2008). See http://fosdem.org. Since I live in Brussels, I will definitely attend and can accommodate one person at no charge. I'm also trying to set up an Ada developers' room with several interesting speeches. That's also a good idea! Do you know the deadline for reserving such a DevRoom? Their website isn't too informative to me today (i.e. DevRooms is an empty page from here). From past experience, the deadline is mid-October. However, this is not set in stone and this year they're having serious problems with the organisation. From yesterday's update on the web site, it seems (some of) the problems have been solved. I would suggest asking for a dev room very soon if enough people are interested. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
Thomas Keller [EMAIL PROTECTED] writes: The problem is already fixed on mainline and goes into 0.37. The roster which is attached to each revision is not removed, thus if you try to commit the same revision again it cannot store the roster (which has then the same revid) again. The fix now just checks if the roster exists before a revision is committed, and if it exists, skips this step. There have been long discussions and explanations why we do not remove the roster on kill_rev_locally, please search the mail archive if interested in the conclusions. Thanks. I approve of not removing the roster and the fix is just fine. BTW, I was not really complaining as the workaround I described (syncing into a fresh database) was rather straightforward. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
Ralf S. Engelschall [EMAIL PROTECTED] writes: I today had to use mtn db kill_rev_locally rev where rev was the head of a branch. First, everything looked just fine. I freshly checked out a new workspace (now based on the previous revision on the branch which is now the new head), performed a mtn log to be sure that just the previous head revision got dropped, etc. Then I edited the sources and tried to commit the changes: Bang! | $ mtn ci -m adjust key modify commands | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys' | terminate called after throwing an instance of 'std::logic_error' | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated | mtn: fatal signal: Abort trap: 6 | this is almost certainly a bug in monotone. | please send this error message, the output of 'mtn --full-version', | and a description of what you were doing to monotone-devel@nongnu.org | do not send a core dump, but if you have one, | please preserve it in case we ask you for information from it. The only way to rescue the situation was to restore the database from the last UFS snapshot (luckily no other changes happended in the meantime) in order to be able to proceed again. For me this looks like mtn db kill_rev_locally rev does not remove _all_ related information of rev and that some remaining/dangling information causes the subsequent commit to break. Hmm... Unfortunately, I was not able to repeat this with a simple test where I created a fresh database, performed three commits and killed the third commit :-( I had the same, or a very similar symptom after killing the head of a branch that happened to be a propagate (A to B) node. I then did mtn propagate B A (which was what I really intended) and got an exception. The killed revision and the new revision had the same revision ID. To correct the problem, I synced the offending database into a fresh one and could then proceed with the propagate and commit. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Initially creating a branch without committing changes?
Thomas Keller [EMAIL PROTECTED] writes: Ralf S. Engelschall schrieb: The only possibility I've found is to manually issue an additional cert for the new branch via: $ mtn cert h:foo.bar.cvs branch foo.bar This worked just fine. But I'm not sure whether whether this really is the correct approach. This is the only way of doing this now. In the sense that mtn approve h:foo.bar.cvs --branch foo.bar does the same thing, that is :) Or am I mistaken? I've filed a bug [0] some time ago for pretty much the same thing. Its an UI bug, which should just be fixed. Thomas. [0] http://savannah.nongnu.org/bugs/?func=detailitemitem_id=18201 -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Ubuntu 6.06
dtempw [EMAIL PROTECTED] writes: Hi Ludovic Thanks for getting back to me. As you can see in the attached screenshot, Ubuntu reports 0.33 as the latest version, I'd like to upgrade all my systems (MacOS, Windows and Linux) to 0.36, but Linux is holding me back. No, Linux is not holding you back. What is holding you back is that you are using a stable long-term support version of Ubuntu: this means no package upgrades unless absolutely necessary (i.e. critical bug fixes but not new features). In fact, your Linux is also being held back unless you've compiled and installed the latest version (2.6.22.4) manually. If you absolutely must have the latest version, upgrade to Debian unstable by editing your /etc/apt/sources.list to point at the Debian repository instead of the Ubuntu ones. Then, do apt-get update; apt-get dist-upgrade. monotone 0.36-1 is in unstable but has not migrated to testing yet, and is being blocked by test failures on some architectures (this is intentional). Of course, by migrating to unstable, you take a risk as the name implies. As far as I'm concerned, I run Debian testing on my laptop and I am content with monotone 0.33-8 and linux 2.6.21-6. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Ubuntu 6.06
dtempw [EMAIL PROTECTED] writes: Dear Monotone developers Is there a debian package for Ubuntu 6.06? This is the LTS version and is what our servers use. There is a Debian package, yes, and there has been one since 2004 or so. I believe Ubuntu contains it, but I have no idea what version or in what section. What does apt-cache search monotone tell you? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Small problem with the latest Debian changes...
Brian May [EMAIL PROTECTED] writes: Ludovic == Ludovic Brenta [EMAIL PROTECTED] writes: Is this something I need to worry about, or should I just apply a bit of patience for a couple of weeks? Ludovic Patience. Boost 1.34.1-2 should migrate to testing in just two days, Ludovic as it no longer has release-critical bugs. What about Debian/stable? The next stable is not due before October 2008, so even more patience is required :) If you mean backporting to Etch, this really depends on a backport of boost to Etch. I have no idea about this. However there is a long-term plan for monotone to not require boost anymore. If and when it happens, that might make a backport easier. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Small problem with the latest Debian changes...
Richard Levitte [EMAIL PROTECTED] writes: since debian/control was changed to require version 1.34.1-2 of the boost libraries, my snapshots will not build on [testing], since the boost libraries haven't come that far yet there. Is this something I need to worry about, or should I just apply a bit of patience for a couple of weeks? Patience. Boost 1.34.1-2 should migrate to testing in just two days, as it no longer has release-critical bugs. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
Zack Weinberg [EMAIL PROTECTED] writes: * To make a Debian release, starting from a release tarball: Rename the release tarball to Debian's convention (monotone_VERSION.orig.tar.gz). Unpack it. Take the diff between the corresponding release tag and the head of n.v.m.debian-diff, and apply it to the unpacked directory. Proceed with dpkg-buildpackage. (You do not simply check out the head of n.v.m.debian-diff and run autoreconf -i, because that risks skew between the generated files in the tarball and the generated files on the branch, which will lead to problems.) Alles klar? zw I kind of disagree with this proposed policy. I find it too complicated and leaves too much opportunity for mistakes. In particular, the part about applying a diff outside of a checkout worries me quite a lot, as it means the Monotone database does not directly contain the Debian scripts that are released. I believe the whole point of maitaining packaging scripts in a version control system is to be able to make packages from within a working copy :) I would propose an alternative: * Create a new independent branch named org.debian.monotone, containing *only* the packaging scripts (i.e. the debian and, if necessary, patches directories). (The new branch name is for consistency with all the other packages I maintain with monotone, but not mandatory; I would replicate this branch to my monotone server on www.ada-france.org). This makes it possible to build a Debian package like so: - unpack the release tarball - rename the top-level directory to monotone_VERSION.orig - cp --archive monotone_VERSION.orig monotone_VERSION - cd monotone_VERSION - checkout --branch org.debian.monotone . - dpkg-buildpackage -i'_MTN|\.mt'(note: this is in my .bashrc aliases :)) I think this is much more reproducible than your proposed policy, and more obviously correct (as opposed to just correct). * Remove the debian/ subdirectory from n.v.m, and thereby from the release tarballs. This removes the need for merges between branches, and most of the associated 'don't' rules and opportunities for error in your proposed policy, and consequently the need to enforce these rules. It also makes the release tarballs more distribution-agnostic. Thoughts? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
Zack Weinberg writes: I think I didn't explain things clearly enough. The Monotone database does directly contain the released scripts, and you could in principle make packages from a checkout of nvm.debian-diff by running autoreconf -i and then dpkg-buildpackage, as long as the current release tarball was sitting in the parent directory. The reason I don't recommend this procedure is simply that it risks autoconf / automake version skew (at best producing unnecessary junk in the .diff.gz, at worst causing build failures). Taking the diff between mainline and .debian-diff and applying it to a non-working-copy unpack of the release tarball avoids this problem. I understand why we don't want to run autoreconf as part of Debian packaging, and I agree with this. I think the origin of the problem is that the files generated by autoreconf are in the release tarball, but not in the working copy after a fresh checkout. How about keeping these files in the .debian-diff branch? That makes it possible to patch them if necessary, too. And without rerunning autoreconf from debian/rules. * Create a new independent branch named org.debian.monotone, containing *only* the packaging scripts (i.e. the debian and, if necessary, patches directories). [...] My problem with this suggestion is that we currently have to make small changes outside the debian directory (see present content of the branch). I would really rather not drag in a build-time patching system for them, especially as IMO storing Debian-specific changes as proper changes to the files in a branch will be more convenient. For instance, if we backport fixes from mainline (which we did do for the 0.35 packages) they'll automatically get superseded by the next upstream release when we merge from trunk to branch. OK, that makes sense. I see the question of whether there should be a debian/ directory in trunk as entirely independent of how the branch holding Debian-specific changes is managed. I like having it on trunk, myself - for instance, it means that schema upgrades can be checked in together with the necessary update to monotone-server.postinst and dummy entry in the Debian changelog. (Although, having just typed that, perhaps we should look for a way to eliminate the need...) OK, that's convenient because you happen to be a Monotone developer and the Debian package maintainer at the same time :) -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Richard Levitte [EMAIL PROTECTED] writes: Zack Weinberg said: zackw On 7/6/07, Ludovic Brenta [EMAIL PROTECTED] wrote: zackw Second, I would indeed encourage you, Richard and Zack, to zackw co-maintain the package. That means, as a prerequisite, that zackw I'd like you to agree on merging your scripts, and on a zackw long-term maintenance strategy. zackw zackw As far as scripts, I don't have any; Me neither. I was wondering what scripts you were talking about, Ludovic. The snapshots I make are a different story, and the script I use there isn't really that interesting for regular releases, as most of it is about propagating from three different monotone branches to a private one. For regular releases, I simply use dpkg-buildpackage (or debuild the last two or three days). By scripts I simply mean the contents of the debian/ subdirectory. zackw I was just taking the official 0.35 release tarball and zackw manually applying relevant bits of the 0.31-8 Debian diff, plus zackw one post-0.35 change. I'd be inclined to track official zackw releases as closely as possible. Richard, what are your zackw thoughts? In complete agreement. Me too. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Jon Bright [EMAIL PROTECTED] writes: Hi, Zack Weinberg wrote: some time to figure it out. [ I am not certain 0.33-2 will actually go into testing after ten days - grep-excuses seems to think bug 425907 is relevant even though it affects 0.31-8 too, and *may* be confused about which boost libraries it needs... but we don't have to worry about that right now, anyway. ] I'm not sure exactly how the excuses script works, but http://bugs.debian.org/cgi-bin/version.cgi?width=;info=1;height=;found=monotone%2F0.31-8;package=monotone;format=png;collapse=0;ignore_boring=0 seems to indicate that it thinks 0.33-2 isn't a direct descendent of 0.31-8 - maybe this is why it thinks that's a problem? I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. So I closed the two bugs; they will not block monotone from going into testing. However, boost has been blocked for 53 days by 2 RC bugs; one of them is fixed in experimental but the other one (#429533) seems problematic. The 0.33-2 in unstable is built against boost 1.34.0-1, which has both bugs. Also, it was built with g++-4.2 (the new default C++ compiler as of two weeks ago), so watch out for any bugs. I think it is appropriate to allow the package to mature a little more in unstable. Personally I run testing and I am content with 0.31-6 for now. (I do have an unstable chroot for building packages). -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Zack Weinberg writes: On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. Argh. So I closed the two bugs; they will not block monotone from going into testing. Was that really the right thing to do? Those bugs are real and present in 0.33-2; it's just that they're in 0.31-8 as well... The bugs said FTBFS but 0.33-2 built just fine on all architectures, so the bugs are gone. That's why I closed them. However, boost has been blocked for 53 days by 2 RC bugs; one of them is fixed in experimental but the other one (#429533) seems problematic. The 0.33-2 in unstable is built against boost 1.34.0-1, which has both bugs. Double argh, and IMO entirely destroys the point of doing 0.33-2 at all; it was supposed to be built against 1.33.1, to avoid those problems and the known bugs in monotone =0.35 when boost 1.34 is in use! Yes. If you want a recent version of monotone on an older version of libraries, the only solution right now is www.backports.org, i.e. the latest version of monotone running on Etch, i.e. using g++-4.1 and boost 1.33.1-10. ... however, I have just installed the 0.33-2 package from unstable, and it sure *looks* like it's built against boost 1.33; are you sure? It is a coincidence that you use the same architecture as Shaun (i386). I'm on amd64, and I would use the version just built against boost 1.34 on the buildds. Also, it was built with g++-4.2 (the new default C++ compiler as of two weeks ago), so watch out for any bugs. ... according to mtn --full-version, this is not true either. Ditto. I think it is appropriate to allow the package to mature a little more in unstable. I'm not proposing to push it in ahead of the 10-day window, but I'd like to see it go in as soon as possible after that. Me too, but as soon as possible really depends on boost. I suggest you contact the boost maintainers, chip in on monotone using the single-threaded version of boost (see the last comment in #429533), and ask what the boost maintainers' plans are regarding the two RC bugs. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] ViewMTN patch: accept timestamps with microseconds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I experimented with importing a project into Monotone using tailor.
This worked well, but the timestamps for most revisions contain
microseconds, like this: 2007-06-27T08:58:38.950999. As a result,
ViewMTN gets a ValueError from time.strptime() when trying to parse
the string, and sends a page with internal server error. The patch
below solves this problem. You can see the result on
http://www.ada-france.org:8081/branch/changes/org.debian.gcc-4.2 . It
Just Works and is very uninteresting :)
Thanks for ViewMTN!
PS. I committed with key [EMAIL PROTECTED] but my usual key is
[EMAIL PROTECTED], also attached, just in case you think I
deserve commit rights on one of your databases. This email is
GPG-signed.
- --
Ludovic Brenta.
[keypair [EMAIL PROTECTED]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6GLKlGOz43GGZxxgHPTunD/7Hj/65RFMW
ygr8wBBu68tYFf8Zgp5h/Szw/sVQi6VUDTZEoojPDhvQET5Ayon2SrmUGMd0vP3yoFIvj1gw
Ap1dAPh1u77uECejVflfIr0uS3q+mrwKn2kUCGxLs3fwq2UQY1gODQnSH2ak0nLv9wIDAQAB#
MIICyTBDBgkqhkiG9w0BBQ0wNjAeBgkqhkiG9w0BBQwwEQQI5E+msA8aSN4CAggAAgEYMBQG
CCqGSIb3DQMHBAgAp0szupRmzgSCAoCMhlSVsTut+bxt2AFtgNEtQjO7D6Je0K0LBiB9W4Ww
TNLJm5XGaBEt0hllEVd1v4x/CU2+6STT8ysmioEFk1WhCeVfYHD5nPyWX74tbx9A6+fVKtOE
MXYCnYU+vFaKb7AHi4VrlvUjy64VpVvAx8YhL6HHLAbHTuhN2TpxqkrQ5Cq/j13uInSO/PBA
VKr7xGPz7kznsoGzgdbjTb1AaHaWk8LvJjsa952WXrsOb+IzlgTXkvnSsgoTu1ROungoGmqI
ZdLA0+vtJLUVKrDvJSzIjuAfoWfYzgtuAHeXpoSEfGFHVGfy6B58inCANDPSVPY0faaZ7z1R
K6305rApGR5gbgcxu4xH5kZvT2Ey8a4dSUECmvjMx94dYJ7qC0/tbS+vYHQd12lgChiLL0Tv
HDw817K/STSN573c4oIf7mGWQEJt1rG8vobeD9h/gf3DlAVeAJWsrrDlepW85kC69AeGxVQX
EraVzj4DLOp6LO39/gb9N1E+xqUSTdCLVHUqv57yd0ZnKERPCvXD4Mp+ZsmYr7QFsv2uBIOf
/t8wLgTxGdCWOmOz5cNKpf6xrKFN5erNgwH6XrrIU/oF6HWuMj/beMNTrh4YdZVKro0Xx0wp
BBEqT++gOu8nlBzbIZ6A8vauaAYlvYmrhd4i2n0Gsvo2mK8YVByaNANcGZdzutnMWSno0KGw
C6mtzrgULSiy5+KfDu9V8hakd9lk7Hd1U7jRwRp/zuS+U17MAj3GYDQR0FZ9/sRMJO641qgp
uah4xd5PNFz+YZI4RWB+AImmIg7OV6NYwJlmHqFsTmQ+5+7FHFasI/mDS28k9jiT7BeFNw4i
eYr4Wrq19IwEvhhNPLBY
[end]
- -
Revision: ef26ac329bb15b7607b0bb473c71c84564a2ac02
Ancestor: 7b40124b48efc337e16111a658ac636ae50ac52e
Author: [EMAIL PROTECTED]
Date: 2007-07-04T14:29:08
Branch: net.angrygoats.viewmtn
Modified files:
common.py
ChangeLog:
common.py: handle the special case when the timestamp in the Monotone
database contains microseconds, which time.strptime cannot parse.
- --- common.py 2504e01f69f99347d0e8706fb7c344c6a6471e43
+++ common.py f8f7c657f7c531ed9c11ec3011b78913d971aa0c
@@ -17,6 +17,12 @@ def parse_timecert(value):
import traceback
def parse_timecert(value):
+# The datetime may contain microseconds which time.strptime cannot parse.
+# Drop them. This is easy because Monotone keeps timestamps in ISO 8601
+# format, so microseconds necessarily start with a period.
+index_of_period = value.find ('.')
+if index_of_period -1:
+value = value[0:index_of_period]
return apply(datetime.datetime, time.strptime(value,
%Y-%m-%dT%H:%M:%S)[:6])
def set_nonblocking(fd):
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGi7G2x9kwJZ3/qtQRAnfJAJ9+ab+eF8s0TqlViyuqFvObzJ9mPgCgtJe0
WbIrPiXvynX6YL+KOb79GAQ=
=b6Oj
-END PGP SIGNATURE-
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Richard Levitte writes: So, from now on, you should be able to install on Debian testing with the following lines in /etc/apt/sources.list: deb http://guardian.lp.se/debian testing/ deb-src http://guardian.lp.se/debian testing/ Those using Debian unstable should of course stay with the following: deb http://guardian.lp.se/debian unstable/ deb-src http://guardian.lp.se/debian unstable/ Shaun, your last upload of monotone to Debian is from March 2007, and testing and unstable still carry 0.31 (0.33 is in experimental). Are you planning to continue maintaining the packages in Debian? If not, I can sponsor Richard, as I am a Debian Developer and an everyday user of Monotone. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fixing poor branch names
Corey Sweeney [EMAIL PROTECTED] writes: Hi everyone. I've been using monotone 0.24 for a while now, and it's been great. When i first started using monotone, i made some bad choices in my branchnames (including one branched called 'initial checkin' :). Now that i understand what the branchnames are for, i'd like to bring my branch names in line with the naming convention. Is there a way to do that without loosing the history? I'd really like to clean up my cluttered namespace. (Please cc me on any responces, as i'm not subscribed to the list) Corey Supposing you want to rename the branch initial checkin to org.corey-sweeney.schmoll, here is how I would do it. I tested this on monotone 0.31 with bash. Step 1: add a new branch certificate $ for rev in $(mtn -d my_db.mtn automate select b:initial checkin); do \ mtn -d my_db.mtn approve -b org.corey-sweeney.schmoll $rev; \ done Step 2: create a new, empty database. $ mtn db init -d new.mtn Step 3: pull everything from the old DB, excluding the unwanted branch certs: $ mtn -d new.db pull --exclude initial checkin file:my_db.mtn '*' HTH Step 4: after verifying the results, overwrite the old db with the new one: $ mv -f new.db my_db.mtn HTH -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] ViewMTN doesn't show the contents of files, getfile.py missing?
Hi folks, I've set up an experimental ViewMTN server at http://www.ada-france.org:8081. This is the standalone server, so no mod_python or apache around. The server is Debian Etch with the following packages installed to support ViewMTN: monotone 0.31-6 gnome-icon-theme python-cheetah The ViewMTN server itself is a checkout of net.angrygoats.viewmtn, currently at revision 7b40124b48efc337e16111a658ac636ae50ac52e (the current head). The problem: ViewMTN doesn't show the contents of files; for an example see http://www.ada-france.org:8081/revision/file/3181b16984c8ac8349456c61ecb7f8bb5d664281/README I think the cause is that there is no getfile.py on the system. Searching the Debian package database, I can see only one package that contains it: python-subversion contains a /usr/share/doc/python-subversion/examples/getfile.py. I'm reluctant to install python-subversion, because it depends on subversion itself, and because the examples directories are not and should not be on the Python load path. How about adding getfile.py to ViewMTN? Or should I get it from another place? Also, the checkout contains a subdirectory web that appears to be a copy of the package python-webpy. I suggest that this directory be removed from ViewMTN and a dependency added in the README file instead. Thanks! -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN doesn't show the contents of files, getfile.py missing?
Never mind, I installed package highlight and that solved the problem. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
