Re: [Monotone-devel] monotone problem importing CVS
Hi Mark, Mark Hagger wrote: It does indeed seem to have helped, although I'm slightly confused as the cvs_import command now seems to require I point it to a specific CVS module, rather than just the CVSROOT as the documention suggests, and as I tried with the previous version. This is intentional. You should import the modules you want from CVS one by one (if you really want everything, you can use xargs or so to get this). -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 0.19
On Fri, May 06, 2005 at 01:15:29PM +0200, Nico -telmich- Schottelius wrote: - You speak about compression/decompression, are there in general processes, which can be optimized? I don't mean algorithms or something like that. In particular, must it be compressed/decompressed at all? Can't the server send it compressed? If it must be decompressed to check the hash, might the compressed image not be retained, to push into the database without need to compress it again? Anyway, is there any point to compressing, these days? Maybe it should be a local repository option. Netsync would adapt to either. Nathan Myers [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone: fatal: std::logic_error: change_set.cc:565: invariant 'I(entries.find(p) == entries.end())' violated
On Fri, May 06, 2005 at 12:34:55PM +0200, Daniel Vogelheim wrote: Hello, You wrote: Usually, what this means is that you tried renaming a file from A to B, but there was already a file with name B in the repository; I'd check to see if that's the case. If so, you need to delete or rename B out of the way, before you can rename A to it. Yes, thank you. I apparently had already added the file in the new location, before reading the manual and deciding that rename is a better way to do this. So the B file was not in the repository, but in the 'work' list. I then deleted the MT/work file, and all went fine. monotone drop works equally well on files that aren't in the repo yet, as well, it undoes a monotone add. :-) For completeness, I'll mention that monotone revert will only work on files that aren't in the repo yet, but it will undo either a monotone add or a monotone drop. (If you try to undo a drop with an add, monotone will think that you have just happened to create a new file with a similar name to an old one, and merging will get confused.) -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone problem importing CVS
On Fri, May 06, 2005 at 10:16:56AM +0100, Mark Hagger wrote: Nathanial, It does indeed seem to have helped, although I'm slightly confused as the cvs_import command now seems to require I point it to a specific CVS module, rather than just the CVSROOT as the documention suggests, and as I tried with the previous version. Ah, oops. The documentation was wrong, and we hadn't noticed; just fixed in mainline. The underlying issue is some impedence mismatch between CVS's trees of versioned files model and monotone's versioned trees of files model; in monotone you always check out and commit a whole tree, so when you import you have to pick which granularity that tree is at. I added that CVSROOT check on the theory that no-one ever really wants that granularity to be all the projects that were ever in this CVS repo, including CVSROOT, etc. :-). -- Nathaniel -- .i dei jitfa fanmo xatra ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 0.19
On Fri, May 06, 2005 at 09:13:14AM -0700, Nathan Myers wrote: On Fri, May 06, 2005 at 01:15:29PM +0200, Nico -telmich- Schottelius wrote: - You speak about compression/decompression, are there in general processes, which can be optimized? I don't mean algorithms or something like that. In particular, must it be compressed/decompressed at all? Can't the server send it compressed? If it must be decompressed to check The server does send it compressed, FWIW. the hash, might the compressed image not be retained, to push into the database without need to compress it again? It's not quite that simple, because there is both delta storage and compression going on, and they interact somewhat differently in netsync and the database; plus, as you note, hash checking. At the moment, IIRC, the sequence on the server is: -- server constructs plaintext of requested version, either by finding it in its plaintext cache, by uncompressing a compressed full version in the db, or by uncompressing some sequence of deltas and applying them to another plaintext. -- server hashes this plaintext, to make sure it hasn't been corrupted -- depending on what the client wanted, the server either: -- compresses this plaintext and sends it -- does an xdelta between this plaintext and the other plaintext the client mentioned, compresses the resulting xdelta, and send it I don't recall exactly what the sequence on the client is, but it's similarly convoluted -- there might be some opportunities to streamline and avoid a passing compress/uncompress, but it's hard to get _too_ far, because of the different needs of local storage and network usage. Keeping a safe design is also a bit of a factor; e.g., one might say pff, the server can skip checking the hash, let the client do it, but it's a bit tricky, because the data verification logic is very low level. It has no idea what the data will be used for. In the broader context of trusting monotone to work right and never accidentally give bad data, that's a good thing... Anyway, is there any point to compressing, these days? Maybe it should be a local repository option. Netsync would adapt to either. There's definitely a point to compressing on the wire. In the db it might be a noticeable win (especially for high-traffic servers), but then again, it might not -- the sanity checking has overwhelmed the basic db traffic in CPU usage for a while, might change as we make sanity checking faster. If you're worried about db read/write speed, not doing delta compression might be the first thing to try; you could do this right now without any changes to the database format or the version fetching logic, you'd just need to tweak the version storage logic not to make the deltas in the first place. -- 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] Fwd: [Contrib-Rpm] monotone-0.19-1mdk
I've packaged monotone 0.19 for Mandriva. It is available from Mandriva's cooker contrib repository. Its was built using gcc 4.0 with CXXFLAGS=-O2 -pipe -march=i586 -mtune=pentiumpro -fno-strict-aliasing and passed a 'make check'. (There was a lot of compiler warnings generated, including a boost library warning about a unsupported gcc version :-) , that I can make available if people want) Cheers, Nick ,--- Forwarded message (begin) Subject: [Contrib-Rpm] monotone-0.19-1mdk From: Nick Brown [EMAIL PROTECTED] Date: Fri, 06 May 2005 17:41:25 +0100 Newsgroup: gmane.linux.mandrake.cooker.cvs [Contrib-RPM] -=-=-=- Name: monotone Relocations: (not relocatable) Version : 0.19 Vendor: Mandriva Release : 1mdk Build Date: Fri May 6 17:50:13 2005 Install Date: (not installed) Build Host: n2.mandrakesoft.com Group : Development/Other Source RPM: (none) Size: 121 License: GPL Signature : (none) Packager: Mandriva Linux Team http://www.mandrivaexpert.com/ URL : http://www.venge.net/monotone Summary : A distributed version control tool Description : monotone is a free, distributed version control system. it provides fully disconnected operation, manages complete tree versions, keeps its state in a local transactional database, supports overlapping branches and extensible metadata, exchanges work over plain network protocols, performs history-sensitive merging, and delegates trust functions to client-side RSA certificates. -=-=-=- Nick Brown [EMAIL PROTECTED] 0.19-1mdk - 0.19 - make check in %check -=-=-=- No rpmlint error, happy (wo)man :-) -=-=-=- http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/contrib-SPECS/monotone/ monotone.spec changed --- monotone-0.18-2mdk.src.rpm/monotone.spec 2005-05-06 18:41:24.394298036 +0200 +++ monotone-0.19-1mdk.src.rpm/monotone.spec 2005-05-06 18:41:24.530279886 +0200 @@ -1,6 +1,6 @@ %define namemonotone -%define version 0.18 -%define release 2mdk +%define version 0.19 +%define release 1mdk %define summary A distributed version control tool @@ -33,6 +33,9 @@ %configure %make +%check +make check + %install rm -rf %buildroot %makeinstall @@ -54,6 +57,10 @@ %doc AUTHORS COPYING NEWS README %changelog +* Wed May 04 2005 Nick Brown [EMAIL PROTECTED] 0.19-1mdk +- 0.19 +- make check in %%check + * Mon Apr 13 2005 Nick Brown [EMAIL PROTECTED] 0.18-2mdk - Make monotone actually work -- http://www.mandrake-linux.com/en/cookerdevel.php3 `--- Forwarded message (end) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 0.19
On Fri, May 06, 2005 at 01:15:29PM +0200, Nico -telmich- Schottelius wrote: Nathaniel Smith [Thu, May 05, 2005 at 04:15:05AM -0700]: [initial-push-discussion] However, the initial pull is on the whole mostly CPU bound; monotone is rather busy doing hashing, compression, uncompression, xdelta calculation and application, and extensive validity checking on all the new data. Thank you for the information Nathaniel! I have just some more questions left: - The cpu load/usage is high on a) the monotone server b) the monotone client? Monotone's basically peer-to-peer. The only difference between client in server is who starts the initial handshake, and that the server may have multiple protocol streams running at once. The main thing that might make a difference for resource usage is that servers tend to send out more revisions than they get in, on balance, and clients the other way around. Anything that might make a client slow can also make a server slow, though, and vice-versa. - You speak about compression/decompression, are there in general processes, which can be optimized? I don't mean algorithms or something like that. I'm not sure what you mean by general process, which can be optimized...not algorithms :-). -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: CLI / path restrictions.
Nathaniel Smith [EMAIL PROTECTED] writes: On Fri, May 06, 2005 at 07:37:36PM +0200, Bruno Hertz wrote: while the user interface might currently not be top priority, are there still any plans to allow for non-recursive path restrictions, e.g. for list various ? Hardest part is coming up with a sensible way for the user to express this desire -- any suggestions? Hmm. Looking at common tools (like ls, chmod or whatever), restriction to pwd is the default, and recursiveness must explicitly be requested, like per '-R' option (OK, not possible with ls, of course). 'find' is one of the notable exceptions, where recursiveness is the default, and limitation to pwd or level of recursiveness is requested per 'maxdepth'. I've seen the term 'depth' already being used somewhere, I think it was the revision history depth of the log command, so there might be some risk of confusing people. But to meet user intuition somehow, I guess either of the above approaches might serve as a model. Also, remotely related and fyi, while diff takes a base name as an argument, log requires a path relative to MT, which some people might consider an inconsistency. Yeah, that's a stupid bug in log. It never got updated to use Derek's no-longer-so-new restrictions stuff. It'd be really nice if it could interpret the pathname correctly (using the same code that, umm, all the other commands that take pathnames use), and if it could take multiple filenames/directories, like all the other commands that restrict to part of the tree... This especially since monotone does up-dir traversal anyway, to find MT. I.e. the relative path to MT is always known, and having to specify it always redundant. Though I guess the semantics of listing a directory are not totally clear; if I say 'log foo/', and there's a file foo/bar that used to be in some other dir, should the log include edits to foo/bar before it was in this dir? if there used to be a file called foo/bar but is no longer, should the log include edits to foo/bar when it was in this dir? I guess my feeling is that log should do something like: for each rev in history: update list of explicitly mentioned files and directories according to any renames that happened on the edge just traversed if this revision has any changes that touch any file that matches anything in the updated list, output this revision The idea being that anything the user explicitly mentioned on the command line, we track its logical lifetime, over renames and all that. And for those which are directories, we reinterpret this restriction again for each historical revision. So the answers to the questions above are that we don't include edits to baz/bar even though it will later become foo/bar; and we do include edits to foo/bar even though it will later become baz/bar. You take the discussion one step further than originally intended, as the above 'dilemma' of course applies independent of how I have to specify a path for log. It's rather a consequence of monotone supporting renames by making trees the primary object of revisions, which is a good thing, btw, and very neatly solved (although, as a sidenote, from what I understand from the docs there's a one to one relationship between revisions and manifests, making me wonder whether there's a redundancy either ...). Anyway, regarding your concern, I guess the log of a dir resp. the content of a dir should contain the actions which happened on that content at each particular revision step (I'm skipping merges for now, since I'm actually no scm geek and have no clear picture on how to proceed in those cases - an issue I've been thinking about these days when wondering about how to present a diff history of a single file). Anyway, as much as a file 'enters a directory' by adding, it basically does the same by renaming. Regarding the directory, the file did not exist there before, and that I think should be the general and imho pretty intuitive semantics of log. Of course, log should report the rename action as such, and in particular what the previous name was. If this was agreed upon, the other direction would follow. I.e. if a file was renamed some time ago and thus left the dir, the log would include the file history up to that point, in analogy to a file removal (you might add here that renaming actually is a re-mv-al on *nix like systems). This way, the complete history of a file is covered, admittedly at then maybe different places but in a clean, logical and consistent fashion users I believe will have no problem with. Even more, users accustomed to thinking in categories of files, directories and paths will presumably perceive any other approach as confusing. Generally, I'm wondering whether it's possible to get rid off the requirement the user entering MT relative paths at all, e.g. by taking pwd into account. Yeah, that we haven't already is just a bug. Do you know of any
Re: [Monotone-devel] [ANNOUNCE] monotone 0.19
On Fri, May 06, 2005 at 10:10:04AM -0700, Nathaniel Smith wrote: On Fri, May 06, 2005 at 09:13:14AM -0700, Nathan Myers wrote: On Fri, May 06, 2005 at 01:15:29PM +0200, Nico -telmich- Schottelius wrote: - You speak about compression/decompression, are there in general processes, which can be optimized? I don't mean algorithms or something like that. ... there is both delta storage and compression going on, and they interact somewhat differently in netsync and the database; plus, as you note, hash checking. At the moment, IIRC, the sequence on the server is: -- server constructs plaintext of requested version, either by finding it in its plaintext cache, by uncompressing a compressed full version in the db, or by uncompressing some sequence of deltas and applying them to another plaintext. -- server hashes this plaintext, to make sure it hasn't been corrupted -- depending on what the client wanted, the server either: -- compresses this plaintext and sends it -- does an xdelta between this plaintext and the other plaintext the client mentioned, compresses the resulting xdelta, and send it I don't recall exactly what the sequence on the client is, but it's similarly convoluted -- there might be some opportunities to streamline and avoid a passing compress/uncompress, but it's hard to get _too_ far, because of the different needs of local storage and network usage. Keeping a safe design is also a bit of a factor; e.g., one might say pff, the server can skip checking the hash, let the client do it, but it's a bit tricky, because the data verification logic is very low level. It has no idea what the data will be used for. In the broader context of trusting monotone to work right and never accidentally give bad data, that's a good thing... It looks to me like the netsync protocol needs a way to ask for much lower-level constructs: basically, Tell me the hashes of all the blobs you have that I will need to construct these versions; I'll tell you which of those to send. Don't bother hashing, because I have to do that anyway. Don't bother with any plaintext, just give me everything raw and compressed, straight from the database. On receipt, the client deflates each blob and verifies its hash, but doesn't bother constructing any final plaintext versions. It just stuffs the verified, compressed blobs into its own database just as they came over the wire. When a user _asks_ for one of those versions it just got the pieces for, it can construct plaintext, check hashes again, and whatnot, as usual. Probably they will never ask for most of the intermediate versions it picked up, so there's no point in fooling with them during netsync. Nathan Myers [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] error importing cvs repository
While importing a cvs repository I got the following error [EMAIL PROTECTED] monotone]$ monotone --db=test.db -- branch=net.example.wobbler cvs_import /home/filippo/ior/cvsmirror/cvsroot/securemail enter passphrase for key ID [EMAIL PROTECTED]: monotone: [branches: 12] [versions: 9147] monotone: phase 1 (version import) complete monotone: [branches: 12] [finished branches: 7] [finished edges: 195] [versions: 9147]build monotone: fatal: std::logic_error: change_set.cc:2551: invariant 'I (b.rearrangement.deleted_files.empty())' violated 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 monotone- [EMAIL PROTECTED] monotone: discarding debug log (maybe you want --debug or --dump?) [EMAIL PROTECTED] monotone]$ monotone --full-version monotone 0.19 (base revision: 168adf9537ff136c9b7fe7faad5991f92859390d) Running on: Linux 2.6.11.7-ac7 #1 Wed Apr 13 01:55:16 CEST 2005 i686 Changes since base revision: new_manifest [52a617d908ac6c4bb5b837ce5306f75155dc59ef] old_revision [168adf9537ff136c9b7fe7faad5991f92859390d] old_manifest [a9ee1d741b855fdcc0d038d64d913cef70da72f5] patch po/monotone.pot from [10e6d7cbad87eaa0dbe35c803cafa371567f024b] to [0465f6ac8d09fac5938ac067747b179aca677b67] 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. Regards, Filippo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Server fails to start up because it messes with MT directory
On 02 May 2005 14:36:41 +0200, Peter Simons [EMAIL PROTECTED] wrote:
Hi,
I've run into the following problem: I start my monotone
Netsync server using a separate user id: 'monoserv'. When I
do so while being in a current working directory which is a
monotone repository though, I get this error message:
monotone: fatal: std::exception:
boost::filesystem::is_directory: /root/MT:
Permission denied
That's what I got while being in ~root, obviously.
Now, I start the process with
--norc --rcfile=/full/path/to/permissions.lua
flags, so IMHO it shouldn't access the local MT directory!
Did I miss something, or is this a bug?
It's trying to read MT/options. Since anything in this file can be put
on the command line (so it's not critical to be able to read this),
here's a patch to turn this into a warning. If there are no
objections, I'll merge it in a couple days.
Tim
#
# patch app_state.cc
# from [da30ae47064dd3743fd31e7ce99dcb9c7fdf7813]
#to [428b3e3ec88e16568de00a00f1b79fb3fe4bb983]
#
--- app_state.cc
+++ app_state.cc
@@ -356,13 +356,19 @@
{
local_path o_path;
get_options_path(o_path);
-
- if (file_exists(o_path))
+ try
{
- data dat;
- read_data(o_path, dat);
- read_options_map(dat, options);
+ if (file_exists(o_path))
+{
+ data dat;
+ read_data(o_path, dat);
+ read_options_map(dat, options);
+}
}
+ catch(std::exception e)
+{
+ W(F(Failed to read options file %s) % o_path);
+}
}
void
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
