[Monotone-devel] Passphrase no more accepted?
Hi I written out the private key, delete db, use a snapshot db and update db. Next I readed back the private key. But if I have to enter the passphrase my password will not be accepted (failed to decrypt private RSA key, probably incorrect passphrase). I am *mostly* sure that the password is correct. Is there a possibility that the password is correct, but failed somewhere else? Im using monotone 0.25. Thanks... Musti ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [ANNOUNCE] monotone 0.26pre2
I'm pleased to announce the release of monotone 0.26pre2, the second pre-release leading up to 0.26. Okay, so mostly this was to make sure that people who hear my codecon talk tomorrow would have something non-embarrassing to play with. But in fact a fair amount of new stuff is in here, and it'd be great to hear how any more testing goes. The status going towards 0.26 is: -- we have found exactly 1 bug in the roster code, and it was extremely minor. I still would not recommend any large project switch to the 0.26 series, yet, but I am getting more confident in it, and am unlikely to look shocked and horrified too much if individuals decide that for them, in their situation, it is worth upgrading for real. -- root renaming, and thus migration of histories which contain root suturing, is still not implemented on mainline. This blocks 0.26. -- roster_merge still lacks unit tests. This blocks 0.26. -- Grahame's bug has not been analyzed. This blocks 0.26. Enjoy, -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Approval revisited...
Nathaniel Smith [EMAIL PROTECTED] writes:
[...]
Personally, I think the functionality of 'disapprove' should move to
'revert' ('revert -r REV [RESTRICTION]; commit'), and 'approve' could
just go away, or stay on until we have a real story, or whatever.
That would stomp over any local changes, wouldn't it?
I like the extended revert. That would let you revert a file or
directory back to whatever it was in some previous revision, which
seems useful.
This all feels close to what patch would do, if it existed. Only
patch would also allow cherrypicking and things. And if we had a
monotone patch -r REV1 -r REV2 (as a useful shorthand for monotone
diff -r REV1 -r REV2 | monotone patch), then that would do the same
as subversion's merge, so there's potential for a bit of confusion, I
suspect.
[...]
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
On Sun, Feb 12, 2006 at 07:47:36AM +0100, Richard Levitte - VMS Whacker wrote: Incorrect. disapprove does what you describe it should do, as follows, except for the merge that you have to do separately: Oh. Er. Um. Well... oops! I blame a flaky memory, and perhaps the fact that the only time I actually used this so far, it was probably to 'disapprove' something that was at least a local head already. Sorry about that. Regardless of what happens to 'disapprove', which at the very least is poorly named, revert -r does sound useful in its own right. For example, in a workspace merge, I could use it to pick files for the merge result as they were in one or the other head being merged. -- Dan. pgp7UF7OqyNgP.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 0.26pre2
On Sun, Feb 12, 2006 at 06:03:14AM -0800, Nathaniel Smith wrote: The status going towards 0.26 is: -- we have found exactly 1 bug in the roster code, and it was [..] -- root renaming, and thus migration of histories which contain root suturing, is still not implemented on mainline. This blocks 0.26. -- roster_merge still lacks unit tests. This blocks 0.26. -- Grahame's bug has not been analyzed. This blocks 0.26. Was kill_rev_locally fixed while I wasn't looking? -- Dan. pgpNfPShCjvhv.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] 1st class branches support in Monotone and usability issues (WAS: cairo, git and mercurial)
Hi, SZ From the usability point of view, first class branches in Monotone SZ has a disadvantage of being completely equal in rights. SZ You can't just pull from remote repository and start browsing the code, SZ you will also need to find out which branch is the main one. Emile Snyder wrote: This is true. I can think of two things that might ease this pain 1. Extend the netsync protocol so that you can easily ask the server what branches it's serving. 2. Also extend it so that it can show you branch groups, where a branch group is the set of branches which are attached to a single connected DAG of revisions. This would let you quickly see when there were multiple projects (ie. no overlapping code) in one repository. Would these changes make the co-equal first class branches more appealing to you? IMHO, the usability problems of browsing a Monotone database can be solved in easier ways, without changing internal algorithms: 1) Allow users to specify the host address with branch name as one entity, instead of two. E.g. use mtn://venge.net/monotone instead of branch net.venge.monotone, which is being served at venge.net. 2) Somehow encourage users to have separate databases for separate projects, so that the problem of repository browsing will not appear. I have learnt not to put unrelated projects on the same database, when I noticed that I spend way too much time on deciding what branch I need to check out, or which branch I need to diff with. This happened just after 'monotone ls branches' became too long to fit into one screen :) However, this learning process would have not been necessary, if the Monotone had the default behaviour of creating a separate database for each new working directory. Below are my thoughts on what in particular can be done in Monotone UI to solve usability issues I've encountered in my practice. This is completely subjective, so it might or might not make sense to other Monotone users. $ monotone setup myproject - current behaviour monotone: misuse: need --branch argument for setup + more usable behaviour: default branch name to directory name, like monotone init myproject -b myproject $ monotone setup myproject -b myproject - current behaviour monotone: misuse: no database specified + more usable behaviour: create empty database in MT/ monotone -d myproject.mtn db init monotone -d myproject.mtn setup -b myproject myproject mv myproject.mtn myproject/MT # and fix myproject/MT/options * initial checkout from remote repository - currently done in 3 commands monotone -d monotone.mtn db init monotone -d monotone.mtn pull venge.net net.venge.monotone monotone -d monotone.mtn checkout -b net.venge.monotone monotone (and I always do then mv monotone.mtn MT/ vi MT/options # to fix the path to the database ) + more usable way monotone checkout mtn://venge.net/monotone # which would have done the sequence of commands described above. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Javascript graph viewer (canvas, so probably not IE)
http://ajaxian.com/archives/new-javascriptcanvas-graph-library Spring-based layout, so not as good as graphviz for the kinds of graphs that we have, but it might be good for a small webserver like what I imagine drh was talking about: a thing you fire up that gives a quick view of a bit of a branch for local viewing. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] viewmtn requires python2.4?
I can see wrapper.py uses string.rsplit, which isn't in 2.3. Are there other more subtle dependencies on 2.4? I'm noticing that diff screens seem to hang. It's no big deal, since I guess debian/unstable will change to 2.4 soon, now that the other major upgrades have all (or almost all) been done. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] invariant 'I(is_valid_internal(data()))' violated
Monotone 0.25 automate inventory is reporting an invariant violation. The problem seems to be a file in my .kde directory. I can reproduce the error by copying .kde into a clean sandbox created from a fresh database. I just built the monotone from the source tarball on SuSE 9.2, using Boost 1.33 from the Packman archives and SuSE packages for everything else. The debug file is attached. Here's a script of how I did it. [monotone]$ monotone db init --db=test.db [monotone]$ monotone --db=test.db --branch=test.branch setup testdir [monotone]$ cd testdir [testdir]$ echo test file test-file [testdir]$ monotone add test-file monotone: adding test-file to working copy add set [testdir]$ monotone commit monotone: beginning commit on branch 'test.branch' enter passphrase for key ID [EMAIL PROTECTED]: monotone: committed revision e80634917e6e100bb9f387f5888d3b542fb6cb35 [testdir]$ monotone automate inventory 0 0 test-file [testdir]$ cp -pr ~/.kde . [testdir]$ monotone automate inventory monotone: fatal: std::logic_error: paths.cc:215: invariant 'I(is_valid_internal(data()))' violated monotone: monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to /srv/monotone/testdir/MT/debugif reporting a bug, please include this file [testdir]$ monotone --full-version monotone 0.25 (base revision: 4f4cb0aa339ad70c5b2624db22073d9e9a36c115) Running on: Linux 2.6.8-24.19-default #1 Tue Nov 29 14:32:45 UTC 2005 i686 Changes since base revision: new_manifest [76b5ea65324372db9886d2c0a8cee8e759841c8c] old_revision [4f4cb0aa339ad70c5b2624db22073d9e9a36c115] old_manifest [76b5ea65324372db9886d2c0a8cee8e759841c8c] Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. started up on Linux 2.6.8-24.19-default #1 Tue Nov 29 14:32:45 UTC 2005 i686 command line: 'monotone', 'automate', 'inventory' set locale: LC_ALL=en_US.UTF-8 initial abs path is: /srv/monotone/testdir initializing from directory /srv/monotone/testdir searching for 'MT' directory with root '/' search for 'MT' ended at '/srv/monotone/testdir' with '' removed working root is '/srv/monotone/testdir' initial relative path is '' options path is MT/options branch name is 'test.branch' local dump path is MT/debug setting dump path to MT/debug skipping nonexistent rcfile '/home/gjditchf/.monotone/monotonerc' skipping nonexistent rcfile 'MT/monotonerc' executing command 'automate' options path is MT/options revision path is MT/revision loading revision id from MT/revision executing SQL 'SELECT sql FROM sqlite_master WHERE (type = 'table' OR type = 'index') AND sql IS NOT NULL AND name not like 'sqlite_stat%' ORDER BY name' result: 0 (not an error) prepared statement SELECT id FROM revisions WHERE id = ? binding 1 parameters for SELECT id FROM revisions WHERE id = ? binding 1 with value 'e80634917e6e100bb9f387f5888d3b542fb6cb35' prepared statement SELECT data FROM revisions WHERE id = ? binding 1 parameters for SELECT data FROM revisions WHERE id = ? binding 1 with value 'e80634917e6e100bb9f387f5888d3b542fb6cb35' old manifest is 6da2b0cf5207d89b7b3381d0a353a160752cfd77 prepared statement SELECT id FROM manifest_deltas WHERE id = ? binding 1 parameters for SELECT id FROM manifest_deltas WHERE id = ? binding 1 with value '6da2b0cf5207d89b7b3381d0a353a160752cfd77' prepared statement SELECT id FROM manifests WHERE id = ? binding 1 parameters for SELECT id FROM manifests WHERE id = ? binding 1 with value '6da2b0cf5207d89b7b3381d0a353a160752cfd77' binding 1 parameters for SELECT id FROM manifests WHERE id = ? binding 1 with value '6da2b0cf5207d89b7b3381d0a353a160752cfd77' prepared statement SELECT data FROM manifests WHERE id = ? binding 1 parameters for SELECT data FROM manifests WHERE id = ? binding 1 with value '6da2b0cf5207d89b7b3381d0a353a160752cfd77' old manifest has 1 entries work path is MT/work no un-committed work file MT/work concatenating change sets concatenating 1 and 0 deltas processing delta on test-file delta on test-file in first changeset renamed to test-file finished concatenation loading lua hook get_linesep_conv lua failure: isfunction() in get_fn; stack = nil Lua::ok(): failed loading lua hook get_charset_conv lua failure: isfunction() in get_fn; stack = nil Lua::ok(): failed ignoring book keeping entry MT loading lua hook ignore_file lua: extracted bool = 0 loading lua hook ignore_file lua: extracted bool = 0 loading lua hook ignore_file lua: extracted bool = 0 loading lua hook ignore_file lua: extracted bool = 0 loading lua hook
