Justin Patrin [EMAIL PROTECTED] writes:
IIRC there are 2 major reasons we're trying to remove the non-geader
stuff in boost.
1) It's a huge stumbling block for people installing monotone. Boost
tends to be a huge pain to build for many people on many platforms.
This seems to have gotten
Zack Weinberg [EMAIL PROTECTED] writes:
branches? Do any work? Which are up-to-date?
...
No work has been done since the summit. The present state of play is,
you can do 'mtn merge_into_workspace revision' which will merge
revision with the current workspace's parent (I forget what
Richard Levitte [EMAIL PROTECTED] writes:
Does that mean that the Windows crowd is uninterested in monotone?
No!
I'm planning on using monotone on Windows/MinGW as a replacement for
CVS, for real work.
I'd also like to port monotone to Lynx. I got it to compile, but the
tests totally fail. It
Zack Weinberg [EMAIL PROTECTED] writes:
If you have a conflicted file in a roster, it is marked as conflicted
in the status output. You get four copies of the file in your
workspace: ancestor, left, right, and merged-with-conflict-markers
(respectively: myfile.ancestor.rev, myfile.revL,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther wrote:
Most of the comments I got on my RFC about the suspend functionality
were positive. The few that weren't seemed to be satisfied with
followup discussion.
An UI doubt just occurred to me: what about a branch that is merged
Hi all,
I’ve got a build slave setup for vs2005 on vista ( build slave
name is i686-winvista-vs2005 http://monotone.ca/buildbot/i686-winvista-vs2005
at http://monotone.ca/buildbot/ ). The unit tests are crashing during the
cset:basic_csets test (The tests previous to this test
Thomas Keller schrieb:
Monotone uses a couple of global macros which error out well-defined if
something went wrong and this even works for the stdio ostream. However,
what you get as error message is still the same one a normal user would
get. You could start stdio or any other mtn subprocess
Hi there,
I get another interesting error message when I try to commit on my
multi-GB database:
$ mtn commit
mtn: beginning commit on branch 'ulfjack.music'
terminate called after throwing an instance of 'informative_failure'
what(): error: sqlite error: SQL logic error or missing database
On Thu, 12 Jul 2007 09:56:32 +0200, Thomas Moschny wrote:
On Thursday 12 July 2007, William Uther wrote:
Given that, I'm going to merge the branch back into the n.v.m
trunk next week unless I hear objections.
We really should release 0.36 beforehands, shouldn't we?
I'm happy to wait a
Zack Weinberg [EMAIL PROTECTED] writes:
Hrm. For a first pass, I'd only allow is_clean_except_for_content()
stuff to be left in the workspace. If there are file-name conflicts
then you must resolve them at merge time. Actually, I'm not really
sure there is another good way to do this as you
Hi all,
I was looking at the dumb pull code again, and decided that was
non-trivial to make useful for beginner end users. At the same time
I live in a world of firewalls and so I can't run netsync on its own
port. Finally, the ssh:// transport scheme locks the db, making it
In message [EMAIL PROTECTED] on Sat, 14 Jul 2007 18:06:36 -0700, William
Uther [EMAIL PROTECTED] said:
willu.mailingListsMy latest approach is to make a new transport scheme;
ssh+ux://
willu.mailingLists and is in the branch: net.venge.monotone.local-sockets.
The server
On 7/14/07, William Uther [EMAIL PROTECTED] wrote:
I've been playing with the branch, and it does slow down listing
branches quite a bit. Listing branches isn't too common an
operation, but I switched things up to try to help this:
- The main 'suspend' cert change is now in
William == William Uther [EMAIL PROTECTED] writes:
William Thoughts?
What benefits do you get in using having socat talk to mtn via a Unix
domain socket instead of the tcp socket on localhost?
I guess there are:
* unix permission checking on socket, so you can restrict access to
certain
On Windows XP mingw I get the following when running make check:
tester.cc: In function `time_t get_last_write_time(const std::string)':
tester.cc:103: error: integer constant is too large for long type
mtn itself is built and seems to work.
On Mac OS X I get:
120 command_outside_checkout
This looks useful.
It would also be handy (mainly for testing purposes) if a server and
client running on the *same machine* could be told to talk to each
other via a network socket. Something like what you have on the
server side, and on the client side, use file:///path to specify the
On 7/14/07, Justin Patrin [EMAIL PROTECTED] wrote:
On Windows XP mingw I get the following when running make check:
tester.cc: In function `time_t get_last_write_time(const std::string)':
tester.cc:103: error: integer constant is too large for long type
*headdesk* This is what I get for
Richard Levitte wrote:
Yes, one: would it be possible to have the server accept connections
both on the usual port and through ssh+ux:?
It shouldn't be too hard. It's more of an interface issue. I'm
actually trying to re-work the interface now so that you can use the
--bind option
Zack Weinberg wrote:
On 7/14/07, William Uther [EMAIL PROTECTED] wrote:
I've been playing with the branch, and it does slow down listing
branches quite a bit. Listing branches isn't too common an
operation, but I switched things up to try to help this:
- The main 'suspend' cert change is
Hi all,
A quick question on the code. In cmd_netsync.cc, about line 60
there is the following code:
static void
find_key(utf8 const addr,
globish const include,
globish const exclude,
app_state app,
bool needed = true)
{
if (app.opts.signing_key()
(BTW, the threading on your messages seems to be broken in my email
reader?)
On Sat, Jul 14, 2007 at 09:03:42PM -0700, William Uther wrote:
Zack wrote:
SELECT child FROM revision_ancestry WHERE child NOT IN (SELECT
parent FROM revision_ancestry)
[snip]
hrm. We'll need to be a little
On Sat, Jul 14, 2007 at 01:59:37PM -0700, William Uther wrote:
I then started looking at why finding branch heads is so slow. The
answer is simple: project_t::get_branch_heads() first gets every
revision in the branch, then erases ancestors. Getting the heads of
every branch means
On Sat, Jul 14, 2007 at 02:17:52PM -0700, William Uther wrote:
I can see what you're saying. There are a bunch of different types
of conflicts, and I think
some could be easily handled with renames. Some seem harder to
handle with renames though.
The design work here has all been done
On Sat, Jul 14, 2007 at 05:23:32AM -0400, Stephen Leake wrote:
Zack Weinberg [EMAIL PROTECTED] writes:
Tangentially, I want conflict marker generation to be left to a lua
hook.
Yes, with a default to the CVS style.
It will probably be with a default to call merge(1), like CVS does
or even
On Fri, Jul 13, 2007 at 12:55:28PM -0700, Justin Patrin wrote:
This is outside an MTN checkout. Within an mtn checkout everything
seems to happen normally. I *was* trying to do a checkout but this
happens with no command-line arguments whatsoever as long as I'm
outside of a checkout.
Anyone
25 matches
Mail list logo
