Re: [Monotone-devel] mtn rename --guess
Timothy Brownawell wrote: On Mon, 2009-01-26 at 22:29 -0600, Matthew Nicholson wrote: Greetings, My rename --guess work from the mini summit is ready for testing and review. It can be found in the net.venge.monotone.rename-guess branch. The rename --guess command attempts to match files in the mtn ls missing list with files in the mtn ls unknown list. Currently the command will detect renames of identical files and renames of directories composed of identical files. Future improvements may include, renames of files and directories with partial content changes. # # patch "cmd_ws_commit.cc" # from [f19eb71e76506b5ac8a706f610e6a34b595266a1] #to [b3bd3a32ee59af9edb595e9c999e937390b9965b] # # patch "options_list.hh" # from [05705dd75c2e3556f4bac136b13c802d85827e0d] #to [54a563f0f12bd6db64856d316d0c7a13cd0125e4] # # patch "work.cc" # from [b005a944d5e5ebcbfed43ac742871eba7d5e7ad0] #to [4b549d6bcb26d3e0632b08d16871195016a66e17] # # patch "work.hh" # from [cd117c8295b2bdf48db35e92aaf29842c27a1b7f] #to [066d38ca737363f32bfe4b4811689d09ee5066d8] # Should have at least one file like tests//__driver__.lua . Yeah, there are several cases I have thought of to test, just haven't gotten around to writing the tests. -options::opts::bookkeep_only) +options::opts::bookkeep_only | options::opts::guess) Later it looks at app.opts.exclude_patterns and app.opts.depth, but it won't accept these options. It should also complain if these are given without the --guess option. Ok, I'll take a look at that. - "SRC1 [SRC2 [...]] DEST_DIR"), + "SRC1 [SRC2 [...]] DEST_DIR\n" + "--guess"), I'm thinking that should probably be "[PATH]... --guess" to be more consistent with other commands that take a restriction. Ok. Trying it out... $ ../nvm.rename-guess/build/mtn rename --guess mtn: renaming a to d in workspace manifest mtn: warning: a doesn't exist in workspace and d does, skipping filesystem rename It really doesn't need to warn about that, should probably do like --bookkeep-only. Yeah. That makes sense. I have just been ignoring those warnings :). Thanks for the feedback. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.asio
Zack Weinberg wrote: (this was meant to go to the list yesterday) On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner wrote: Hi, Zack Weinberg wrote: This has been proposed several times. Sorry for bringing this up again, then. But I don't remember any such discussion since using boost headers only. Hm, the last time I remember it coming up was at the face-to-face conference back in 2007(?) and of course you weren't there. Sorry. There are technical reasons (having mostly to do with the complexity and abnormality of boost's build system) why it has never been done, but I do not think they are insurmountable. A build system? You don't need no build system for header files. I was going to say that we would at least need the logic to generate boost/config.hpp but it turns out that's all done with #ifdefs when the thing is used, which is not completely crazy as it means you can use one installation with many compilers. However, I don't want to count on it staying that way. Or put the other way around: what does using the system provided headers buy us here? It's not like distributors gain anything by building "against" system headers - unlike with libraries, where replacing the library could fix security issues in monotone (as well) or some such. If we use the system provided headers, then when there is a security issue in boost, distributors only have to apply the patch to their boost package and then recompile everything that depends on it, which is highly automated. If we bundle our own copy of boost headers, they have to keep our package on a special list of additional places to patch when there is a security issue in boost. Let me restate my position a different way: I think there are significant advantages to shipping *none* of the libraries we depend on: we make life easier for Linux-style binary distributors, who only have to carry one copy of any given piece of source; we make life easier for ourselves, as we do not have to watch for new releases of the libraries and do the integration work; we don't have to carry around any pieces of the libraries' configuration scripts in our own, and we don't lose performance because we left that piece of the configuration out to save hassle (e.g. for Botan's assembly optimizations). There are also different, significant advantages to shipping *all* of the libraries we depend on (with the possible exception of zlib, which is so stable and so ubiquitous that no one has ever had a problem to date with our not shipping it): we control the exact version of each library we use, so we're insulated from API churn; we can apply local patches to fix problems that affect us, before new library versions come out; we make life easier for people building from source on systems poor in libraries, e.g. windows. Any point in between those extremes gets the downsides of both and only some of the advantages of either. In particular, we don't make it significantly easier for people building from source unless we ship all the packages, and we don't make it significantly easier for distributors - or ourselves - unless we ship none. I think there is a middle road, though. Let .stripped become mainline. Then we revisit the .library-build branch, where we package up exact copies of all the upstream libraries we depend upon, in sibling directories to our own code. We can then offer two tarballs - the "thin" one with no upstream code, and the "fat" one that includes everything and builds it all from source. I think this is a great idea. I haven't looked at the library-build branch yet, but off the top of my head we could basically just use the build system of each library and make them install into a special staging dir, then build monotone against that statically linked. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: more on commit without -b option
Derek Scherger wrote:
On Wed, Jan 21, 2009 at 12:52 PM, Derek Scherger <mailto:de...@echologic.com>> wrote:
When commit opens your editor to write a changelog maybe it should
load the buffer with something that looks a *lot* like a committed
revision as listed by log. Then, you not only get to see the
Ancestor, Author, Date and Branch values of your pending commit but
you could also *edit* them before saving the log and actually doing
the commit. This essentially changes the format of messages coming
back from the commit hook and requires them to have some structure.
After getting the message from the hook it would be parsed and the
various values would be used for their respective certs.
I've pushed a couple of revs to
net.venge.monotone.experiment.changelog-editor that essentially
implement this different style of changelog editing. Having used this
new changelog editor to commit the two revs involved in its
implementation, it seems quite nice to be able to "see" what the
revision will look like and to edit the branch you're committing to in
the process of writing or finalizing the changelog. The idea that status
shows a rev you're working on, commit shows the same thing as you're
committing it and log shows the same thing later seems good to me.
There are a few more changes I'd like to make before I'd call this
branch finished but I'd like to get some feedback and see what people
think first before spending time on them:
(1) We have two different forms of revision summary, one used by commit
and status and another used by log. These should probably be unified, I
prefer the one that status and commit use slightly. The log output
contains "Ancestor:" lines that should probably be "Parent:" to be
consistent with other tools and more correct.
(2) The revision_summary function in cmd_ws_commit.cc uses
(F("...")).str() += "\n" which looks quite odd and I wonder if there's
any real point or if it could use an ostringstream to good effect.
(3) The get_log_message_interactively function in cmd_ws_commit.cc
claims "Lines beginning with `MTN:' are removed automatically." but
doesn't do anything with them. They are instead handled by the lua
edit_comment hook. It seems odd to separate these things but that may be
unavoidable in the current arrangement. This new branch removes this
stuff altogether.
I can see a few potential problems with this branch or objections to the
change in general and I'm curious if they're real or if I'm imagining them:
(1) It's a sufficiently different way of editing a changelog that no
other vcs that I know of currently does and may put people off or
confuse them the first time they use it. People may just not like it
because it's different.
As long as the user is not forced to do anything different than other
vcs systems, I don't think this is a problem.
(2) It will break scripts or other tools that currently use the output
from status or log or use commit in certain ways. These things are
probably supposed to be using the automate interface but they may have
no choice if the features they need are lacking. (monotone.el comes to
mind as something to be checked; dvc.el as well presumably)
Hmm... as long as they are still easily human readable, I don't have a
problem with it.
(3) The api changes to the edit_comment hook will break anyone who has a
custom hook. Will a simple NEWS entry regarding this suffice?
This could be a problem, especially for people who don't read NEWS
before an upgrade. Breakages may just be something we have to deal with
though.
Comments?
I think this is a good feature. Being able to change information about
the commit is useful from the commit message. As long as these changes
don't change things for users who are used to just editing the commit
message, I don't have a problem with these new options.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.asio
Markus Wanner wrote: Hi, Matthew Nicholson wrote: From a packager's standpoint, using the system headers makes security bugs more explicit. If the packager's build system knows that monotone has a build time dependency on a particular library (even if it is header only) and a security bug is found in that library, then the packager knows it needs to recompile that library. If the library is bundled in monotone, that information is lost. Thank you for this feedback from a packager's point of view. However, unlike you seem to assume, recompiling the library does *not* help with this kind of dependency. You need to recompile and repackage monotone. In this regard, header-only dependencies are rather different from library dependencies. Yeah. That was supposed to say recompile monotone, but you get the idea. But, yeah, I take the point that packagers like the information that monotone is "build time dependent" on boost. That would get lost if we drop the dependency and incorporate the headers. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] mtn rename --guess
Greetings, My rename --guess work from the mini summit is ready for testing and review. It can be found in the net.venge.monotone.rename-guess branch. The rename --guess command attempts to match files in the mtn ls missing list with files in the mtn ls unknown list. Currently the command will detect renames of identical files and renames of directories composed of identical files. Future improvements may include, renames of files and directories with partial content changes. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: more on commit without -b option
Stephen Leake wrote: Derek Scherger writes: dvc.el as well presumably) I'm maintaining the DVC mtn interface; this will have no impact. On the other hand, I would like to propose a related change. DVC allows the user to create _MTN/log as part of the process of reviewing the files to be committed. Therefore there is no reason to pop it up in an editor to be confirmed. That's fine; 'mtn commit --message-file' does not ask for confirmation. However, this command does insist that _MTN/log be empty, even if the file specified is _MTN/log. That's just annoying; DVC has to rename _MTN/log to some other name, and clean up. DVC edits _MTN/log, rather than some other file, because then the user can conveniently fall back to the command line if they really need to for some problem. So I'd like to drop the insistence on _MTN/log being empty if --message-log = "_MTN/log". Any objections? Sounds good to me too. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.asio
Markus Wanner wrote: Hi, Zack Weinberg wrote: This has been proposed several times. Sorry for bringing this up again, then. But I don't remember any such discussion since using boost headers only. There are technical reasons (having mostly to do with the complexity and abnormality of boost's build system) why it has never been done, but I do not think they are insurmountable. A build system? You don't need no build system for header files. However, I am not a fan of this idea, because it would mean that we would have to incorporate part of boost's build system somehow. I'm proposing to add just the headers, no build system, nothing else. We just got done ripping out most of the bits of other libraries' build systems that we had incorporated. My main motivation for going after netxx is not to solve the problems associated with netxx itself (although those are present in my mind) but because it would let us kill off the remaining stuff in the configure script and Makefile that's there for someone else's code's benefit rather than our own. Adding those headers would allow us to rip out even more from the autoconf stuff. Especially dropping a dependency which has posed problems for many people on various platforms. Also, packagers, in general, *want* to carry build dependencies on their already-packaged libraries rather than rely on bundled versions. Again, this is not about libraries, but only about header files. I absolutely agree with you regarding libraries. Also keep in mind, that we currently advice people to just download the boost sources and use its header files. That certainly doesn't run them through any build system either. Let alone a test suite. I fail to see any disadvantage for including these headers, compared to this approach, which seems rather silly to me. Or put the other way around: what does using the system provided headers buy us here? It's not like distributors gain anything by building "against" system headers - unlike with libraries, where replacing the library could fix security issues in monotone (as well) or some such. From a packager's standpoint, using the system headers makes security bugs more explicit. If the packager's build system knows that monotone has a build time dependency on a particular library (even if it is header only) and a security bug is found in that library, then the packager knows it needs to recompile that library. If the library is bundled in monotone, that information is lost. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted netsync (was: merging in "serve raw 'automate stdio' over network")
Timothy Brownawell wrote: I should also mention that I'm thinking we eventually want to move to SSH2 for encryption/authentication (pending finding a good server-side SSH2 library, there only seem to be client-only libraries available now). This would let us only need to listen in one place for both netsync and stdio (and whatever else we might come up with), and would also mean not needing to keep our own authentication code or write our own encryption code (I know I've seen requests for encrypted netsync). Why ssh2 and not ssl/tls encryption? Just curious. I imagine ssl libraries would be more prevalent. And instead of relying on SSH for authentication, we could add the option of using PAM for authentication which is what SSH uses anyway. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mini Summit 2009
Markus Wanner wrote: [...] Hi, I am here now, and I will be here for the rest of the evening and tomorrow after noon (America, South East (CDT)). I am willing to lend a hand to help anyone who needs it (testing, coding, whatever). Personally, I am interested in working on some of the quickie tasks on the wiki and some other things, specifically. * a mtn rename --guess command, or mtn rename --missing * mtn detach and mtn attach * concurrent access to a single database (not sure what is involved with this one, so I will need your help). I am 'man' in IRC (and matthew_i as well when I am at work). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: January Mini Summit (Jan 17th and 18th)
Philipp Gröschler wrote: Lapo Luchini schrieb: Method of meeting… IRC, I guess? Wiki says so. (if we're too few people Skype-conference might be easier, as it leaves hands free for writing code…) But IRC could be logged and sometimes people might want to leave their desk for a short time. I have no problem with using skype in addition to IRC. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] January Mini Summit (Jan 17th and 18th)
Greetings, Just a reminder, the Mini Summit is scheduled to take place in 10 days (probably 9 for some people). Please post your ideas on http://monotone.ca/wiki/MtnSummit/2009/. My hopes are that that summit can jump start monotone development efforts a little bit. See you there! P.S. Unfortunately I will not be able to participate until the evening of the 17th, so you will have to start with out me. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Thomas Keller wrote: Hi Matthew! At first thanks for taking the initiative to organize the Mini Summit! You wrote: I have started a wiki page[1] with these ideas. Feel free to edit that page, and please also continue to discuss ideas on the mailing list. I would like to have a solid list of things to work on by January 12th, and then flesh those out for a week until the 17th so that we have a solid agenda for our virtual summit. [1] http://mtn-wiki.1erlei.de/wiki/MtnSummit/2009 What I'd like to see even more than another list of wanted features are a couple of people who put their names here on the list or on this wiki page saying "yes, I want to _work_ on this topic and I think I _can_ do it!" If this does not happen, I'm afraid this gets another wishlist which won't be implemented anytime soon. Great idea. I also think we need some kind of guide to monotone development (which we may already have). This guide would contain descriptions of the macros we use and the principles that monotone is developed by. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Lapo Luchini wrote: Matthew A. Nicholson wrote: No one strongly objected to the January 18 and 19, 2009 time frame Wasn't it 17-18? January 19 is a monday =) Yes that is correct, my mistake. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Timothy Brownawell wrote: On Fri, 2008-11-28 at 13:21 +0100, Philipp Gröschler wrote: Matthew A. Nicholson wrote: Please add your ideas to this list. * Concurrent access to a single Monotone database This has been discussed a few times, I'm not sure if a solution has already come up. A few ideas on this topic have been floating around for a while. As far as I'm concerned, I'd like to have one database file to which I sync from my workstation or laptop, and have another process (viewmtn or a self written PHP equivalent) accessing that database at the same time. Maybe for this specific problem there could be other solutions (besides mtn automate) than concurrently accessing the repository on the database/sqlite level. nvm.tbrownaw.serve_automate may be interesting here, along with the hacked viewmtn and usher included in nvm.contrib.webhost . It adds a --bind-automate option to mtn serve, so it can serve automate stdio over the network (without any authentication or access checking, so don't put it on a public address). * Integrating a 'branch rename' command Currently I have a shell script available which was posted on the Monotone Wiki some time ago. With future changes to monotone it maybe uncertain how long that script will keep working. Next point is, one does always need to have that script available, since renamings must happen on all affected locations. Therefore, and as I have to use branch renaming quite often, it would be nice if that function could be integrated into the mtn binary. Policy branches! :) I have started a wiki page[1] with these ideas. Feel free to edit that page, and please also continue to discuss ideas on the mailing list. I would like to have a solid list of things to work on by January 12th, and then flesh those out for a week until the 17th so that we have a solid agenda for our virtual summit. [1] http://mtn-wiki.1erlei.de/wiki/MtnSummit/2009 -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Summit thoughts - and changes?
Lapo Luchini wrote: Markus Wanner wrote: Hi, Lapo Luchini wrote: Other people? Comments? December doesn't work for me anymore... sorry. I think December is probably a bit hard for many of us… Christmas, New Year and all the things they go together with (work to be finished in the fiscal year, presents for friends, family dinners and so on…). Shall we propose something in the January timeframe? Weekend 3rd-4th I'm away, but the next three are good for me (at least right now). What about 17th-18th January 2009? Let's decide early so each of us can write it in the calendar and Just Be There ;) Those dates work for me. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Summit thoughts - and changes?
Matthew A. Nicholson wrote: On Fri, Oct 17, 2008 at 11:12:08AM +1100, Daniel Carosone wrote: [...] Discuss. :) -- Dan. I think this is a great idea. Why don't we set a date for the next virtual summit. Perhaps the first full weekend in December (the 5th-7th)? Or is that too close to thanksgiving (US) or christmas? So what about these dates? Or others? -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Win32 fork() for test suite (was: new test --no-workspace)
Zack Weinberg wrote: On Sat, Oct 25, 2008 at 3:08 PM, Stephen Leake p.s.: legendarily, there *is* an undocumented Win32 system call equivalent to fork(); anyone who wants to find that and use it instead of this rather rube-goldberg mechanism will probably be rewarded with a faster test suite. A quick google search appears to point to NtCreateProcess as having similar functionality as the unix fork() function. http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2008-04/msg00272.html http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/NtCreateProcess.html -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Stephen Leake wrote: Matthew Nicholson <[EMAIL PROTECTED]> writes: Zack Weinberg wrote: On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: * lua: pretty similar to sqlite, except the source inclusion variant is a bit more complicated. I'm all for dynamic linking and don't see much of a reason for source inclusion. I think I mentioned this before, but if we're going to stop bundling lua we have to overhaul the error-handling interface between lua and our code, because we're currently relying on lua's ability to be compiled as C++ and use C++ exceptions to report errors. Of course we need to overhaul it *anyway* because right now lots of errors just silently get lost, but remember that this is on the critical path for unbundling it. Yeah, I recently noticed the same issue. To properly unwind the stack on error in a c++ app, lua needs to be compiled with a c++ compiler. It uses setjmp and longjmp for error handling when compiled as C and exceptions when compiled as C++. If we don't require stack unwinding on error (I have not looked at the code), then dynamic linking is fine, but I think this is a candidate for bundling. I'm confused. You seem to be implying that a dynamically linked object file cannot be compiled with a C++ compiler. Is that correct? Or is there some limitation on dynamically linked object files, that says they can't propagate exceptions? It has nothing to do with linking really. It's all about how lua signals errors. If there is an error in some lua code, or c++ or c code called from a lua function, that error is handled at the location of the nearest lua_pcall() usually. If compiled as C code, lua jumps to that location using setjmp and longjmp, c++ exceptions are used if compiled as c++. This is a special c++ exception that is caught by lua (not by the host application). When using set/longjmp the stack is not unwound, so no c++ destructors are called. This can cause memory and other resource leaks. So this was not completely clear from the other responses. To help visualize this, draw an imaginary line between lua code and c++ code called from lua and monotone's other c++ code. Errors (C++ exceptions) are not supposed to cross this line. Basically the way to signal errors from lua code is by calling the lua_error() function (or just error() from lua code or luaL_error()). This will cause lua_pcall() to return the error to the host application. I'm not sure if throwing a c++ exception from lua code will cause any problems or not. If we are very careful and make sure all clean up is done in the event of a lua error then there are no problems using the C version of lua but this is generally difficult to do. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Markus Wanner wrote: In the archive I've read that boost::program_options didn't do what we want. Looking at the boots documentation, I also see boost::asio - could that perhaps be a better replacement for the (unmaintained) netxx? Anybody used boost::asio before? I use boost::asio in my astxx library. I have not had any problems with it, seems well designed. Also there is a non-boost version of it for the anti boost crowd (I happen to be pro-boost). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Zack Weinberg wrote: On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: * lua: pretty similar to sqlite, except the source inclusion variant is a bit more complicated. I'm all for dynamic linking and don't see much of a reason for source inclusion. I think I mentioned this before, but if we're going to stop bundling lua we have to overhaul the error-handling interface between lua and our code, because we're currently relying on lua's ability to be compiled as C++ and use C++ exceptions to report errors. Of course we need to overhaul it *anyway* because right now lots of errors just silently get lost, but remember that this is on the critical path for unbundling it. Yeah, I recently noticed the same issue. To properly unwind the stack on error in a c++ app, lua needs to be compiled with a c++ compiler. It uses setjmp and longjmp for error handling when compiled as C and exceptions when compiled as C++. If we don't require stack unwinding on error (I have not looked at the code), then dynamic linking is fine, but I think this is a candidate for bundling. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions about Monotone
Daniel Carrera wrote: Hello, I am currently a Darcs user and I'm interested in Monotone's greater data integrity assurance. But I have a question about committing: I am the sole programmer at a small business. Often I will be working on Feature_A when something else comes up (Issue_B) that requires immediate attention (boss wants a new feature asap, customer has a problem, etc). So I deal with Issue_B and when I'm done I go back to working on Feature_A. My work is a web application, so it is perfectly reasonable to solve Issue_B, send the changes to the server and then continue with Feature_A. Anyways, at this point I would like to commit the changes related to Issue_B. But I already have a bunch of changes for Feature_A and I don't want to mix the two together. These are logically different changes and should be on different patches. I would like to know how Monotone could help me deal with this situation. This situation happens every week. I am often working on improving the crappy source code I inherited from my predecessor or fixing security issues while the boss wants to add a new feature. So I need a simple way to say "put these changes in the patch but don't include these other ones". My current solution is Darcs, which indeed makes the above easy. When I run "darcs record", darcs shows me the changes one at a time, and I can tell it which ones to include in the patch. Another equally good solution is: (1) record the current changes for Feature_A, (2) work on Issue_B, (3) record the changes for Issue_B, (4) UN-DO step (1), and continue working on Feature_A. This latter option is actually more useful. Anyways, does Monotone offer either solution to my problem? Or perhaps it offers a third solution that I have not thought of yet? Thanks, Daniel. When I need to do things like this, I check out a new workspace (mtn co ../new-work-space) and then I make the hot fix change there and commit it. This keeps your Feature_A change from being included in the commit. You could also do this in a separate branch. After you commit the hot fix (Issue_B), you can continue working on Feature_A as you were, commit and then merge later (mtn commit, mtn merge, see monotone branches can have two heads), or you can merge that change into your Feature_A workspace (mtn up) and continue from there. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Comparison of Monotone and git
William Uther wrote: The interesting part here is that Monotone has a global namespace for branches, whereas git has a local namespace for branches. By default in git you get a 1:1 local:remote branch name mapping, but you can rearrange that if you wish. This removes the need for centralised control of branch naming (policy branches) - it is all just local. I like the idea of local branch namespaces. How do they implement it? Just use like the sha1 hash of various things as the true branch name and then map that to a texual name locally? -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone displays commit times in UTC, not local time
Zack Weinberg wrote: On Wed, Jun 4, 2008 at 3:25 AM, Tim Kettler <[EMAIL PROTECTED]> wrote: I just noticed that monotone displays the commit time for changes (printed by 'mtn log') in UTC and not my local time. Is this the wanted behaviour? If not, does anybody else see this or is it just some misconfiguration on my machine? I wouldn't call it _desirable_, but it is the expected behavior. Dates are stored as strings in the database, in exactly the format you see them, in UTC. When they're printed, we just print them out as strings. This is because doing a time zone conversion is fraught with portability issues, and so it's more trouble than anyone's wanted to go to. Feel free to send in patches :) zw Boost.DateTime can parse the exact string that we store in the database and convert it to local time. It should be an easy patch to write. Not sure how that would affect performance or if we are willing to link with boost date_time. P.S. I noticed this issue too, and it is kind of annoying. It makes using the dates in monotone some what difficult. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug #21545 -- really annoying
Markus Schiltknecht wrote: Yury Polyanskiy wrote: Please consider this bug... It always causes problems when updating upstream releases: you update, make a tag then realize that something was missing and you have to add the tag again. Hm.. I see your point. However, there is 'mtn add --recursive', which you might want to use together with '--missing'. I got hit by the same problem recently before I realized i needed --recursive. Does it make sense to make this recursive by default? I guess if I wanted to only add unknown files in a specific directory, I could use a restriction to the current dir (mtn add --unknown .). I remember some discussion about mtn ls unknown and such always acting from the root directory a while back. -- Matthew Nicholson matt-land.com ___ 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
Markus Schiltknecht wrote: Hi, William Uther wrote: An example: how is bob expected to resurrect a file "foo", which got overridden by another node id which is now called "foo". I can only think of something like "take file 'foo' from rev '1234..' but name it 'bar'", which will quite certainly make bob become crazybob. That looks much like subversion's copy feature. I think that would make merging hard for monotone. It is a complete break with the current 'mark-merge' philosophy. I was trying to say that it's hard for the user to specify which node id she wants to resurrect, in case its filename got reused by another node. It's an argument against concentrating on node ids, and has not much to do with the implementation. I suppose that could be a little complicated, but as you said it could be something like: mtn ls dead foo mtn resurrect a1b2c3f foo The ls dead command would show dropped nodes by file name and the revision they were dropped in, the mtn res command would resurrect them. Also UI wise, the obvious resurrection case is when a revision with dropped nodes is reverted/disapproved, those nodes should come back, right now they don't (they are replaced with new nodes with the same content). -- Matthew Nicholson matt-land.com ___ 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
William Uther wrote: On 07/05/2008, at 1:21 PM, Matthew Nicholson wrote: William Uther wrote: This third option would avoid the drops entirely. It has the problem that I don't know how to reverse it. i.e. if you merge two node-ids then you could never tease them apart again. Hrm. You could just introduce a new node-id with the current contents, but you'd have lost some of the details in the history. Reversal involves making two new node id's each with the sutured node as a parent. Not sure what you mean by 'parent' here. If you mean 'parent' in the revision parent sense, then that is confused - we're talking about files, not revisions. If you mean 'parent' in the union-find algorithm sense then what you describe will not achieve a split - both new node id's would end up having the same 'set' according to the algorithm and you have achieved nothing but a slight slowdown. I realize we are talking about files not revs. The only way I can imagine making a 'split' is the simple one of making a new file with the current contents - think 'copy'. Hrm, I guess you could make it symmetric and create two new ids (kinda like two copies and a drop), but I'm not sure that is an advance. I believe this is what I just suggested. History is preserved and the files are split again. This of course is roughly equivalent to the copy/split operation I have seen floating around. This is a tricky problem. e.g. a b \ / \ c d |\ /| | e | | | f | \ / g Lower case letters are revisions, not files. a and b each create a file 'foo'. I'll refer to them as fooa and foob. c sutures the two foos together - making fooc. d edits foob. e merges the changes made in d to foob into fooc. f splits fooc into ?? g merges d and f. What happens to the changes to foob in rev d? Are they dropped? Are they merged into both child nodes of fooc? Only one child node, and if so, which? No imagine another child revision of a that makes changes to fooa. It then gets merged with rev g. What happens now? So this sort of thing makes me want git's throw "history to the wind and worry about content" approach, but we can approximate that with fancy UI. Basically you have another non-content conflict when g merges d and f. In f you have split files, we will call them food and fooe, in d you have foob. I don't know how monotone's merger works, but I imagine, when it is time to merge f and d, the merger looks at fooe and food and realized they have a common ancestor in foob. The conflict happens because we don't know if we should merge foob with food and/or fooe or if we don't merge at all and just have a non content conflict (to be possibly resolved by suturing foob with fooe and/or food. That is very confusing. If we just treat these files as if they were revisions then what happens? First we have to pick either fooe or food to suture foob with because foo has "two heads" (the heads being food and fooe (and foob really)). Once we pick one, we have resolved the conflict, as the newly created foof will be a non conflicting file as will which ever "head" (food or fooe) remained. I believe the right way to suture and copy/split[1] is to have node DAGs which you have partially described in your emails with your parent node/replacement node talk. [1] (really copy and split are two different operations) -- Matthew Nicholson matt-land.com ___ 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
William Uther wrote: This third option would avoid the drops entirely. It has the problem that I don't know how to reverse it. i.e. if you merge two node-ids then you could never tease them apart again. Hrm. You could just introduce a new node-id with the current contents, but you'd have lost some of the details in the history. Reversal involves making two new node id's each with the sutured node as a parent. History is preserved and the files are split again. This of course is roughly equivalent to the copy/split operation I have seen floating around. At the moment dropped node-ids are gone. Introducing a graveyard means keeping all node-ids around. The standard thought for resurrection is to keep them around with an 'isLive' boolean attached to them that can be mark-merged. But once you're keeping around all the node-ids, it wouldn't be hard to keep around more information. That extra information could be the "replacement" node-id for node ids that were dropped as part of a suture. The extra information could be the 'parent' node-id from a disjoint sets data structure. This is very similar to what I was thinking when the "atomic drop two add one" idea was first presented. This is basically a combination of your options i and iii, although with pure option 3 you don't need the graveyard. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Inconsistent behavior: clone vs checkout
Thomas Keller wrote: Matthew Nicholson schrieb: So, Should mtn checkout be modified to work like mtn clone? I know it has been mtn co -b ... for ages, but should it be changed to mtn checkout branch.name dir? That would make it more like mtn clone and also more like svn checkout. On downside, mtn co ../new_ws (something I do often), might try to check out the '../new_ws' branch and fail. Again, we're planning to get rid of -b on the long term, so it will be removed from checkout one or the other day as well. Thomas. Ok. I didn't realize how extensive your "no more -b" discussions were. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Inconsistent behavior: clone vs checkout (was: Inconsistent behaviour and others: clone vs. pull)
So, Should mtn checkout be modified to work like mtn clone? I know it has been mtn co -b ... for ages, but should it be changed to mtn checkout branch.name dir? That would make it more like mtn clone and also more like svn checkout. On downside, mtn co ../new_ws (something I do often), might try to check out the '../new_ws' branch and fail. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Inconsistent behaviour and others: clone vs. pull
Thomas Keller wrote: >> (2) The fact that the server does not know they I try to authenticate with is denote with this cryptic message: mtn: warning: protocol error while processing peer monotone.ca: 'received network error: remote public key hash '9625eeea718bd974563ddedde9ff00e3195449a9' is unknown' Could not change that without rewriting parts of netsync I probably do not fully understand - so not a quick hack :-/ Whenever "nuskool" (the highly anticipated, new network protocol) gets ready, we should think about this problem again and fix it early enough. I would have to say, I describe my feelings about nuskool as "worried" and "curious" rather than "anticipatory", but then again, I don't know much about it. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Inconsistent behaviour and others: clone vs. pull
Thomas Keller wrote: Matthew Nicholson schrieb: Dennis Schridde wrote: (3) clone takes a -b argument to specify the branch, while pull wants it as a normal argument. The first time I used mtn clone, I found this a little strange too. Every command in monotone except the netsync commands uses the -b flag. Perhaps we should slowly transition mtn pull/push/sync to use -b instead of a branch pattern. Although this would also raise the issue of passing a branch pattern to -b which is not consistent with how -b works in the rest of monotone. On the summit we've actually talked about the opposite: remove the various places where -b is used (f.e. commit -b) and replace the option's "special" functionality either by making it a first-class argument or by creating new commands (for commit -b some kind of 'mtn branch' or 'mtn switch' command). Interesting. I did find mtn commit -b unintuitive the first time I used it. It makes sense now, but I don't use it (I edit _MTN/options). If there was a mtn branch (which I think just got merged?) I would use it. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Inconsistent behaviour and others: clone vs. pull
Dennis Schridde wrote: (3) clone takes a -b argument to specify the branch, while pull wants it as a normal argument. The first time I used mtn clone, I found this a little strange too. Every command in monotone except the netsync commands uses the -b flag. Perhaps we should slowly transition mtn pull/push/sync to use -b instead of a branch pattern. Although this would also raise the issue of passing a branch pattern to -b which is not consistent with how -b works in the rest of monotone. P.S. Dennis, it looks like the proper authorities are ignoring you :). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht wrote:
Hi,
Timothy Brownawell wrote:
It will be in addition to the current syntax, so what works now will
still work.
Okay, that's fine.
Yes, '&' and especially '!' aren't good characters for shells. I think
I'll use the suggestions of '/' and '-' instead (still in the query
string instead of the path, so it'll work with file:// and ssh:// sync).
Yeah, that looks better for shells. However, I'm wondering somewhat how
you want to find the end of the URL and beginning of include/exclude
patterns.
So, am I right in assuming we are talking about such URLs like these:
* mtn://monotone.ca/net.venge.motonone*
* mtn://monotone.ca/net.venge.motonone*-net.venge.monotone.experiment
* file:/tmp/test.db/org.foo*/org.bar*-org.foo.unwanted/org.bar.unwanted
Do we still need the asterisk? Quite a while ago, Lapo was complaining,
that net.venge.monotone* would not only mean branches net.venge.monotone
and net.venge.monotone.*, but also net.veneg.monotone-foo. That's a
valid concern, IMO.
>
Now, I know we didn't ever hardcode the dot as a branch name separator
(IIRC). However, most people *are* using dot-separated branch names. And
for policy branches - possibly also for nuskool - we should probably
switch to enforce such a hierarchical branch naming anyway.
I don't like this idea. One of the things I like about monotone is that
it does not force you to think like its developers think when it comes
to naming branches. As a side note, I do like '.' as a branch
separator, but not the reverse domain name prefixes (I think some sort
of namespace support would be better).
So, I'm proposing to get rid of the asterisk entirely, making
"net.venge.monotone" mean: that branch and "net.venge.monotone.*" (but
not "net.venge.monotone-foo". I'm assuming that's what you want most of
the time anyway. If you really want to sync only "net.venge.monotone"
and none of it's children, you'd have to explicitly exclude them. So it
would look more like:
I don't think making net.venge.monotone mean
{net.venge.monotone,net.venge.monotone.*} is a good idea either. When I
ask for net.venge.monotone that is what I want, not it and all of its
children. If I want all of its children, I can explicitly ask for those
too. In fact, I have never wanted all of its children.
* mtn://monotone.ca/net.venge.motonone
Or for nvm only, excluding child branches:
* mtn://monotone.ca/net.venge.motonone-net.venge.monotone.*
As we need to change branch naming policies (prohibit use of '-' and
'/') it seems like it's a good time for rethinking branch naming policies.
This would break some existing databases (mine being one) and would
either need to be handled by supporting branch renaming (magical policy
branches?) or by renaming the branches as part of a migration (which is
difficult to handle automatically).
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn:// sync
Timothy Brownawell wrote: On Wed, 2008-03-19 at 20:12 -0600, Derek Scherger wrote: Timothy Brownawell wrote: I've just added support for mtn:// URLs for push/pull/sync. They look like mtn://server?include&!exclude , I chose this over something like I'm not entirely clear on what this means. I would expect something like mtn://server?include=pattern&exclude=pattern I think. Is this what you mean? Perhaps an example url or two would help. Maybe just the "!" in your example above is confusing me. mtn sy monotone.ca nvm* --exclude nvm.experiment* would become mtn sy mtn://monotone.ca?nvm*&!nvm.experiment* Personally I think that looks horrible and confusing vs the --include --exclude syntax. The variant that has ?include=pattern&exclude=pattern is slightly more readable, but I still prefer the command line switches. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Improved Vim Merger
Brian May wrote: "Matthew" == Matthew Nicholson <[EMAIL PROTECTED]> writes: Matthew> P.S. I am not sure if anyone other then me is using vim Matthew> to merge, it seems like a lot of you use real merge tools Matthew> (e.g., kdiff3, xxdiff, ...). vim merge has the advantage (compared with kdiff3 and xxdiff) that it doesn't require X, so I think it is valuable to keep in monotone. Having said that, as most of my monotone projects only have one contributor (myself!) I don't often encounter conflicts... This change has been committed. I do have some concerns that not having the ancestor available for reference might make some merges more difficult, but further usage will show if this is a valid concern. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] IPv6 addresses and ports (and netxx)
Nathaniel Smith wrote: On Wed, Mar 05, 2008 at 08:19:31AM +0100, Lapo Luchini wrote: Which leads me to the following question: is upstream netxx still alive? The answer is "no". Perhaps we should start a branch to replace netxx with boost::asio[0] which is similar in design and functionality and maintained upstream (and will be a part of the next major boost release). [0] http://asio.sourceforge.net/ -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Improved Vim Merger
Greetings,
I have attached an improved vim merger which uses diff3 to merge non
conflict changes before passing the files on to vim. If there are no
objections to these changes, I will go ahead and commit them.
Further information:
In short, vim's merger sucks. In fact, it is not a merger at all, it is
really a diff tool that will show you the differences between files and
allow you to copy those differences between files. To compensate for
that, this new merger hook calls diff3 to merge the left and right files
so that you only see non conflict changes in vim. This makes using vim
to merge files much more pleasant because you now, don't have to sort
through all of the non conflicting changes when merging large files.
P.S. I am not sure if anyone other then me is using vim to merge, it
seems like a lot of you use real merge tools (e.g., kdiff3, xxdiff, ...).
--
Matthew Nicholson
matt-land.com
mergers.vim = {
cmd = function (tbl)
function execute_diff3(mine, yours, out)
local diff3_args = {
"diff3",
"--merge",
"--easy-only",
}
table.insert(diff3_args, string.gsub(mine, "\\", "/") .. "")
table.insert(diff3_args, string.gsub(tbl.afile, "\\", "/") .. "")
table.insert(diff3_args, string.gsub(yours, "\\", "/") .. "")
return execute_redirected("", string.gsub(out, "\\", "/"), "",
unpack(diff3_args))
end
io.write (string.format("\nWARNING: 'vim' was choosen to perform external
3-way merge.\n"..
"You should merge all changes to *LEFT* file due to limitation of
program\n"..
"arguments.\n\n"))
local vim
if os.getenv ("DISPLAY") ~= nil and program_exists_in_path ("gvim") then
vim = "gvim"
else
vim = "vim"
end
local lfile_merged = tbl.lfile .. ".merged"
local rfile_merged = tbl.rfile .. ".merged"
-- first merge lfile using diff3
local ret = execute_diff3(tbl.lfile, tbl.rfile, lfile_merged)
if ret == 2 then
io.write(string.format(gettext("Error running diff3 for merger
'%s'\n"), vim))
return false
end
-- now merge rfile using diff3
ret = execute_diff3(tbl.rfile, tbl.lfile, rfile_merged)
if ret == 2 then
io.write(string.format(gettext("Error running diff3 for merger
'%s'\n"), vim))
return false
end
os.rename(lfile_merged, tbl.lfile)
os.rename(rfile_merged, tbl.rfile)
local ret = execute(vim, "-f", "-d", "-c", string.format("file %s",
tbl.outfile),
tbl.lfile, tbl.rfile)
if (ret ~= 0) then
io.write(string.format(gettext("Error running merger '%s'\n"), vim))
return false
end
return tbl.outfile
end ,
available =
function ()
return program_exists_in_path("diff3") and
(program_exists_in_path("vim") or
program_exists_in_path("gvim"))
end ,
wanted =
function ()
local editor = os.getenv("EDITOR")
if editor and
not (string.find(editor, "vim") or
string.find(editor, "gvim")) then
return false
end
return true
end
}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: n.v.m.debian branch
Shaun Jackman wrote: > (CC'd monotone) > > On 9/26/06, Matthew A. Nicholson <[EMAIL PROTECTED]> wrote: >> Shaun, >> >> Have you had a chance to review the n.v.m.debian branch? Richard and I >> have been testing it (Richard more than I), and it seems ready for prime >> time. > > No, I haven't. That's rather lame of me, I admit; my Debian > responsibilities fall between the cracks when work and life becomes > busy. My first priority with monotone is to fix the `Fails to Build > from Source' bug that has affected monotone since 0.29 now. Could you > lend some time to help me troubleshoot? > > Cheers, > Shaun > > http://bugs.debian.org/384565 I check that bug out. I thought you had it handled. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] chryn (was pretty pretty pictures (for some value of pretty))
Nathaniel Smith wrote: What would you think if the next time you ran "mtn log" you got something like (using some fictionalized history from "chryn", an async IO library): Have you seen boost::asio (http://asio.sourceforge.net/)? It is an async network IO library. It will be in the next version of boost maybe. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction
Wim Oudshoorn wrote: Nathaniel Smith <[EMAIL PROTECTED]> writes: Questions, comments? I have tried a few times to understand the versioned policy discussions, but everytime I ended up even more confused. So is it possible to have a few detailed use cases. Take for example the problem of revoking commit access. It is easy to state it just like that: I want to revoke commit access for user joe. However this leaves out a lot of details on the actual expected behaviour of monotone. All I see is a discussion about trust seeds and trees and no detailed use case yet. And this might be just me, but it makes it much harder for me to reason about the probosed solutions. It's not just you :). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] non-content conflict...
Richard Levitte - VMS Whacker wrote: In message <[EMAIL PROTECTED]> on Sun, 27 Aug 2006 09:27:22 +0200 (CEST), Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> said: I've figured out what happened, btw. This is part of my build if snapshot Debian packages, and to do those, I propagate nvm, nvm.debian and nvm.levitte.select-heads-of into a private branch, richard.levitte.org:compilations.monotone The conflict above occurs because the *file* debian/examples was just created in nvm, while the *directory* debian/examples/ has existed in nvm.debian for a while. I understand that's an impossible situation. So, at this point, I'd like to ask the Debian savvy, what's the correct path of action? I'm guessing the directory debian/exmaples/ in nvm.debian should be renamed, but I'm not entirely sure. Maybe the contents (read-permissions and write-permissions) should simply be moved down to the directory examples/ and then debian/examples/ should be removed? (Matthew Nicholson, since you created the nvm.debian branch, what's your take on this?) Ok, on nvm.debian, the debian/monotone-server.examples is where that stuff should go rather than debian/examples. I dropped debian/monotone-server.examples and then renamed debian/examples to debian/monotone-server.examples. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pidfile cleanup
Nathaniel Smith wrote: On Thu, Aug 24, 2006 at 08:55:03PM -0500, Matthew Nicholson wrote: Nathaniel Smith wrote: On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote: Did the new signal handling stuff (to fix the delay/freeze after ctrl-c on mtn log) fix pidfile cleanup? The test seems to still be an xfail. Umm, no... forgot about that :-). It should be straightforward enough to come up with some hack to make it work, though -- we have signal handlers, just need to teach them when a pidfile exists, and to delete it, using some signal-safe code. (The main thing to watch out for with such code would be "never allocate memory". Calling unlink(2) should be fine, though.) Hmmm... Right now it looks like the signal handler just prints a message and exits. Right. pid_file tries to clean it self up when it is destroyed. I don't like the idea of just sticking random stuff in the signal handlers (didn't we just remove the journal clean up/db roll back?). Right -- you can't stick random stuff in there, it doesn't work :-). In particular, it's not possible to tell sqlite "do a rollback, but _don't touch malloc while you're doing it_", which is what was causing the crashes -- a signal would arrive while we were already inside a call to malloc, which had locked the mutex protecting the heap, and then the signal handler would call malloc, which would block waiting for that mutex to become available... However, removing a pidfile _can_ be done safely, if one is careful, and the exercise does seem worthwhile. Just need some way for pid_file and the signal handler to coordinate their actions. I like the idea of converting the signal handler into an exception in some safe manner. I am aware that you can't just throw an exception, and there is no straight forward way to do it that will work in every case, but that is the cleanest way I can think of to deal with it. My favorite method is to have some sort of flag that gets checked in various places. If the flag is set then an exception is thrown. This adds some overhead of course (but not much). Either way, this is a very tricky issue to solve elegantly. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pidfile cleanup
Nathaniel Smith wrote: On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote: Did the new signal handling stuff (to fix the delay/freeze after ctrl-c on mtn log) fix pidfile cleanup? The test seems to still be an xfail. Umm, no... forgot about that :-). It should be straightforward enough to come up with some hack to make it work, though -- we have signal handlers, just need to teach them when a pidfile exists, and to delete it, using some signal-safe code. (The main thing to watch out for with such code would be "never allocate memory". Calling unlink(2) should be fine, though.) Hmmm... Right now it looks like the signal handler just prints a message and exits. pid_file tries to clean it self up when it is destroyed. I don't like the idea of just sticking random stuff in the signal handlers (didn't we just remove the journal clean up/db roll back?). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] pidfile cleanup
Greetings, Did the new signal handling stuff (to fix the delay/freeze after ctrl-c on mtn log) fix pidfile cleanup? The test seems to still be an xfail. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Best practice using monotone
Andy Jones wrote: This is brilliant, thanks. Some stupid questions (the best kind): Monotone doesn't care what branches are called, and you can rename branches later on. Err, how do you do that? You mentioned kill_branch_certs_locally... http://www.venge.net/monotone/wiki/BranchRenaming explains it, it is some what of a hack. === Vendor Branch Pattern So to my way of thinking we have vendor branches, working branches, and release branches. And we also have - what would you call them? "fork" branches, as in the "muffins" example from the tutorial. While these are really all the same animal they should be thought about in different ways. I guess you are already saying that by calling them patterns. === Release Branch Pattern Hmm. Is your "deliverables" branch a release branch, or is it a fifth animal? BTW are you really saying that you can rename a file in the deliverables branch, merge it back with the working branch (at which point the name magically changes back), change it, propogate back into the deliverables branch, at which point the name changes back +again+? Good grief. Even if CVS had a rename command, doing all that would cost most developers half a day and two near heart-attacks. Think of all those merge tags...! Don't group many changes together into a single commit. Do a commit for each logical change. This makes it easier for others to "pluck" or cherry pick only the changes they are interested in. For example, commit bug fixes and feature enhancements separately. Should feature enhancements have a seperate branch? Or, one branch per enhancement? How many branches is too many? This very point is why I'm glad to see the "pluck" command. In my job, I make a lot of little fixes ... I see that it's normal at Venge.net <http://Venge.net> to use tags within the working branch to mark releases. It seems to me that that would be redundant if you used your "deliverables" branch pattern, because it would later become the release branch. The start of the branch would always point to the start of the release - or am I missing something? In CVS of course it's de rigeur to tag the point where you fork a branch. I can't work out how (in Monotone) you would select the start of a branch otherwise, so I suppose it's still needed. Unless of course you never needed to refer back to the start of a branch... There are some nasty cases in CVS where if you repeatedly merge one branch with another, Bad Things Happen. Because the common ancestor is still the same, CVS tries to do the previous merge a second time. I take it Monotone has no such problems? Correct, monotone has no such problems. If you try to pluck the same thing twice it will try to do the previous merge again, but if you propagate or explicit_merge it know how to handle data you already merged. This is one of the reasons I like monotone over SVN. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Best practice using monotone
Andy Jones wrote: Can anyone point me to a discussion on best practice using Monotone? It seems to me that the problem is that you can use mtn in so many different ways. How many local databases do you need? How many different ways are people using branches? Tags? How do you integrate all this into release control? I've found some articles on the Wiki, but I find I keep getting surprised (like pulling a branch from contrib into my local database and finding that there is no good way to remove it). Jack's post provides a lot of suggestions on most of your questions. I generally use monotone in the same way the monotone project does except I name my branches in the URL style ([EMAIL PROTECTED]/branch or matt-land.com/branch). As for the number of local databases to keep around, I generally have one per project. So I have one for monotone, one for my website... -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Branch Propagation
[EMAIL PROTECTED] wrote: no, pluck is for basic cherrypicking - applying patches without their dependencies (ancestry) explicit_merge seems to be what you want (plus an improved propagate UI that allows selecting between heads) Ok, i'll try explicit_merge. Thanks. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Branch Propagation
Matthew Nicholson wrote: Greetings, It appears you can only propagate from the head of one single-headed branch to the head of another single-headed branch. Is this an artificial restriction that monotone places or are there logical reasons other similar operations are not possible? I am interested in propagating from a tagged revision to the head of my current branch (mtn prop t:monotone-0.28 net.venge.monotone.debian). Is this what mtn pluck is for? -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Branch Propagation
Greetings, It appears you can only propagate from the head of one single-headed branch to the head of another single-headed branch. Is this an artificial restriction that monotone places or are there logical reasons other similar operations are not possible? I am interested in propagating from a tagged revision to the head of my current branch (mtn prop t:monotone-0.28 net.venge.monotone.debian). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
