There is also the issue with compiling monotone on 'older' platforms.
For example, I still provide packages for Ubuntu 8.04, which has an
older version of pcre. Does stripped support pcre 7.4?
-- Ulf
On Tue, Jan 27, 2009 at 5:31 PM, Zack Weinberg za...@panix.com wrote:
(this was meant to go to
from de.original.branch.
Anyway, I'll be gone for the christmas holidays. No more debugging
until the 31st.
Merry christmas everyone,
-- Ulf
On Sun, Dec 21, 2008 at 11:49 PM, Thomas Keller m...@thomaskeller.biz wrote:
Ulf Ochsenfahrt schrieb:
Hi everyone,
using monotone 0.41 (base revision
Hi everyone,
using monotone 0.41 (base revision:
9b264ec9247ce99cd1fdc5293e869c1a60b01c4c), I get two different
(probably unrelated) crashes on two different databases. Both are
repeatable.
When I try to sync my university database with the monotone server I
setup in the office, I get:
Hello everyone,
I was just syncing when I got a monotone crash, as you can see from the log
below. It's not reproducible - second sync worked. I'm posting it here to
preserve the log in case someone encounters this again. No core dump,
apparently.
Cheers,
-- Ulf
[EMAIL
Bruce Stephens wrote:
Derek Scherger [EMAIL PROTECTED] writes:
Even if size does have to traverse a list to count the elements one would
expect that traversing an *empty* list should be reasonably quick.
Sure, but presumably the extra cost is traversing a non-empty list to
find that it's not
Bruce Stephens wrote:
Ulf Ochsenfahrt [EMAIL PROTECTED] writes:
[...]
If there is an invalid pointer in the non-empty list, the program
can crash.
It can crash, but this is presumably in the realm of undefined
behaviour, so arbitrary things are permitted to happen.
If the compiler
Bruce Stephens wrote:
Ulf Ochsenfahrt [EMAIL PROTECTED] writes:
[...]
What about inifinite loops? The linked list could also loop back to itself.
Is there any guarantee that a std::list is a linked list? Is it
possible to produce a cycle in a std::list? Is the behaviour of
size
Zack Weinberg wrote:
On Sun, Sep 14, 2008 at 2:04 PM, Ulf Ochsenfahrt [EMAIL PROTECTED] wrote:
By the way, why does the new monotone-viz package only have a recommends for
monotone? monotone-viz does use the automate interface. Left-over from an
earlier version?
As far as I know, it can read
Hi everyone!
The old monotone-viz package (which was 0.15 still) didn't work with my
new monotone package (0.41), so I've uploaded new monotone-viz packages
to my personal package area:
https://launchpad.net/~ulf-ofahrt/+archive
Cheers,
-- Ulf
PS: Should I add a conflict to the monotone
Richard Levitte wrote:
In message [EMAIL PROTECTED]
on Thu, 20 Mar 2008 15:08:56 +, Peter Stirling
[EMAIL PROTECTED] said:
peter Is using '' a good idea
is the standard parameter divisor for parametrised URLs, so you
can't get away from that without getting trouble...
I've just
Jack Cummings wrote:
On Wed, Mar 12, 2008 at 05:10:16PM -0400, Zack Weinberg wrote:
Here's my oprofile run script:
Also thanks, but you don't answer the question I was trying to ask:
What are you doing *with monotone* while you're profiling?
Good question. This binary does quite a few
Hi!
I havn't had internet access at home for the last 4 month, and monotone
has been a life-saver. The killer-feature for me is being able to sync
multiple projects at once (as long as they are in the same db). I take
my laptop with me to work (where I do have internet), sync it there, and
Derek Scherger wrote:
The idea I had in mind would be something like, commit the current
revision to your local db *without* a branch cert, but perhaps with some
other paused cert that gives a name to each paused revision. This commit
would be done by the pause command. After committing the
William Uther wrote:
On 06/09/2007, at 7:47 PM, Ulf Ochsenfahrt wrote:
Maybe monotone could do with a 'project' entity (policy branches?),
which collects multiple branches. Then you'd have a
net.venge.projects.eric project which would name all the branches you
are working on, and sync them
Eric Anderson wrote:
I'd be happy with this if the default was mtn pull default_host
current-branch, but the current setup which has the pull use the
first branch ever pulled doesn't work well if you're working on
multiple projects. I also wouldn't want it to do a mtn update unless
there are
Nathaniel Smith wrote:
The main concern people had was of plain 'mtn update' misbehaving when
people were offline -- hanging for a long timeout, blowing up, etc.
Not sure how much of a problem that would be in practice. One way to
find out would be to just enable it and see who screams :-).
I
Nathaniel Smith wrote:
On Wed, Sep 05, 2007 at 02:04:23PM +0200, Ulf Ochsenfahrt wrote:
Nathaniel Smith wrote:
The main concern people had was of plain 'mtn update' misbehaving when
people were offline -- hanging for a long timeout, blowing up, etc.
Not sure how much of a problem that would
Markus Schiltknecht wrote:
In my case, I certainly don't want to trigger a sync before each and
every update. Instead, something like at startup, then every 30 minutes
and before shutdown fits my workflow much better. And if you are now
thinking cronjob!, you've just stumbled across another
Ulf Ochsenfahrt wrote:
Hi there,
I get another interesting error message when I try to commit on my
multi-GB database:
$ mtn commit
With a more recent version of monotone:
monotone 0.35 (base revision: 850fc61ed4c0721851f41e91dceb07c23bd01163)
I get a failure right away:
$ mtn commit
mtn
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
Nathaniel Smith wrote:
On Thu, Jul 12, 2007 at 11:34:45PM +0200, Ulf Ochsenfahrt wrote:
I'm currently using a statically compiled binary of monotone which
weights in at 40 MB. I wanted to get the huge db fix on my laptop, and
the easiest way was to do a static compile on my work machine
Hi all,
I get a weird error message when using monotone on my super-mega-giga
sized project:
mtn: error: error accessing file /home/ulfjack/.monotone/heavymetal.db:
Value too large for defined data type
I get this error message whenever I try to access the database in any
way whatsoever,
Derek Scherger wrote:
Anyway, I should play around with it some more, it does seem reasonable
and there's nothing wrong with fast!
A wise man once said: Premature optimization is the root of all evil.
And I pretty much agree with that. Give me a program that works, rather
than one that is
Paul Crowley wrote:
Ulf Ochsenfahrt wrote:
A wise man once said: Premature optimization is the root of all
evil.
It was Tony Hoare, though Knuth popularized it. See:
http://www.acm.org/ubiquity/views/v7i24_fallacy.html
Interesting. I didn't mean to start a flamewar, I just meant
Markus Schiltknecht wrote:
Humpf... I've just added a 'path::status cached_status;' to any_path,
with an additional which returns that or gets the status.
The problem now is, that this routine needs to *write* the status into
any_path.cached_status, requiring that the any_path in question is
Bruce Stephens wrote:
At work, we keep dependencies checked in (we build on some platforms
which can't easily generate dependencies automatically, so we've
always just checked them in).
Often, when I've used mtn diff to generate patches, the dependencies
fail to apply with GNU patch.
Maybe
Hi,
Max Nickel sent a patch to the mtteam mailing list that he got from mtn
diff. I tried to apply this patch with the unix 'patch' command, but
that did not work, although the patch looks very much like a 'diff'
patch. Upon further investigation, this seems to be due to the line
endings in
Nicolás Ruiz wrote:
Ulf Ochsenfahrt wrote:
I doubt this can be fixed without breaking the user interface on windows
machines. However, it would be nice if we got mtn patch that accepts mtn
diff patches. Wasn't someone working on that?
I'd rather have a mtn diff that works just like unix
Brian May wrote:
Daniel == Daniel Carosone [EMAIL PROTECTED] writes:
Daniel If you see a problem at any of these stages, where you've
Daniel added a file you didn't want, you can always drop that
Daniel file again before committing, and there'll be no record of
Daniel it.
If
Brian May wrote:
Daniel == Daniel Carosone [EMAIL PROTECTED] writes:
Daniel Yes, I know I could use add -R --unknown.
The only problem I see here is that --unknown should probably imply
-R.
This is a special case, I can't see any time I would want to use
--unknown in non-recursive mode.
Jon Bright wrote:
Hi,
Nathaniel Smith wrote:
That's a very good question -- we have a few associated projects
(at least guitone, mtteam, perhaps botan/ajisai if we are serious
about switching to SSL) that might have good sized projects for SoC,
and could benefit from the help.
I'd be happy
Hi,
this was previously discussed here:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/4051
and here:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/10444
So far I have been entirely unable to convince anyone that this is an
important topic, so let me try
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 02 Mar 2007 19:13:39 +0100, Ulf Ochsenfahrt
[EMAIL PROTECTED] said:
ulf Richard Levitte - VMS Whacker wrote:
ulf You know, this wouldn't be such a problem if we could just teach
ulf virtual domains to monotone
Nathaniel Smith wrote:
On Fri, Mar 02, 2007 at 03:37:50PM +0100, Ulf Ochsenfahrt wrote:
*snip*
Note that the way netsync is currently set up, every new revision is
first sent without any branch info, and then the branch info is sent
for that revision. So effectively every branch cert you send
Hi,
I've just been bitten by an old non-feature that has been there for at
least 1 1/2 years, discussed here:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/4051
A friend of mine accidently created a new branch and synced it to my
server, where he has write access. The
Matt Johnston wrote:
Personally I'm not sure this is a good idea. On multi-user
systems, I usually make a point of keeping standard dot
files (.muttrc, .pwm/*, .zshrc, .ssh/config etc)
world-readable, as it's a useful way of teaching people how
to use less-known program features.
Maybe changing
Thomas Keller wrote:
Since Nathaniel's last post about the MTN Summit in the US didn't made
much echo (in comparison to this - sorry - stupid longish line ending
thread(s)), and since some of us (at least me) cannot afford to come to
the US, I thought its time to make a real plan for a European
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Mon, 27 Nov 2006 08:49:26
+0100, Ulf Ochsenfahrt [EMAIL PROTECTED] said:
I've no problem going with that.
Now, what happens if you leave it disabled, but someone else asks
monotone to convert between CRLF (native) and LF
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Mon, 27 Nov 2006 00:37:12 +, Bruce Stephens
[EMAIL PROTECTED] said:
monotone Brian May [EMAIL PROTECTED] writes:
monotone
monotone Richard == Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:
monotone
monotone
Larry Hastings wrote:
Ulf Ochsenfahrt wrote:
Yes, but UTF-8 is a _multi-byte_ encoding.
If you see an LF byte, you don't know whether this is a single-byte LF
or part of a multi-byte sequence.
Yes you do, because all multi-byte character sequences in UTF-8 have the
high-bit set. If you see
Hi all,
This line ending thing is getting far too much attention, IMHO. My last
word on this issue is:
- Whatever I check in, I want checked out
- What I'd like to see is a setting where monotone checks on commit if
the files obey a particular line ending convention/charset and gives a
Kelly F. Hickel wrote:
Then you got
* stable
|\
| \
| * development
| |
| | continue to work on development
| .
| continue to work on stable
.
and at some later point
.
|
* .
\ |
\|
* can merge from stable into development
[Kelly F. Hickel] Well, this is an interesting idea. In
Thomas Keller wrote:
2. Error Handling
Right now, automate stdio handles errors by exiting the mtn instance.
So you'd need to be able to start a new 'server' from your
php/java/c/whatever anyway.
Only hard errors exit the instance (i.e. which make stdio unusable for
further commands),
Thomas Keller wrote:
4. Limited Operations
automate stdio doesn't support such basic operations as add, drop,
rename, or commit.
This is just because there is not enough man power involved (most of the
commands require a lot refactoring since automate.cc isn't yet split
like command.cc is).
Brian May wrote:
Hello,
If I delete a directory that contains no files but don't tell
monotone, monotone forgets about it:
...
Is this expected behaviour?
It's been doing this for quite some time.
mtn ls missing is your friend.
Cheers,
-- Ulf
smime.p7s
Description: S/MIME
Hugo Cornelis wrote:
heccer-passive-1.tar.gz
heccer-passive-2.tar.gz
heccer-passive-3.tar.gz
and
heccer-active-1.tar.gz
heccer-active-2.tar.gz
heccer-active-3.tar.gz
and so on.
This automates building releases, and avoids human errors. The
release number is saved in a small database,
Timothy Brownawell wrote:
On Sat, 2006-10-28 at 23:57 +0200, Ulf Ochsenfahrt wrote:
Attached is a patch that changes mtn default behavior to add
non-recursively and uses the -R option to reenable old behavior. This
patch makes the add and drop commands more similar.
I've committed changes
Hi all!
I've got a few questions. Some of these may already have answers, others
may not. I looked into the manual and checked the monotone built-in
help, but found no easy answer to these.
- How does monotone select a (default) key to sign?
- How can I find out which?
- Why is automate
[EMAIL PROTECTED] wrote:
Isn't bzr based on svn? Does this mean we've also accomplished
conversion to bzr?
Nope. bzr is a rewrite of baz (in python), which is based on tla, which
is/was a rewrite of larch (in C). larch was originally written by Tom
Lord in shell script.
The bzr people
Hi,
I'll try pasting together the answers from Richard and Timothy.
- How does monotone select a (default) key to sign?
Richard:
If you only have one private key, monotone will choose it (I think, I
haven't tested that for a while).
If _MTN/options has a key identity in it, monotone will
Timothy Brownawell wrote:
'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can
we add a --non-recursive and kill --depth?)
Attached is a patch that changes mtn default behavior to add
non-recursively and uses the -R option to reenable old behavior. This
patch makes the add
Nathaniel Smith wrote:
That gives 6 possibilities:
1. no private key, no key set - error, can't commit
2. no private key, key set - error, can't commit
3. one private key, no key set - private key is default
4. one private key, key set - if both keys are the same, that one is
default, if set
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 26 Oct 2006 18:45:36 +0200, Christof Petig
[EMAIL PROTECTED] said:
christof Ulf Ochsenfahrt schrieb:
christof P.S. and Offtopic: Flirting with my girlfriend is _not_ allowed. ;)
christof
christof that nearly counts
Jeronimo Pellegrini wrote:
If you can label computers as trusted and posibly hostile, then
you can encrypt the database -- and never checkout or have the
clear version on the hostile hosts. You would only decrypt it in trusted
hosts where you'd keep your workspace. A solution based on
Cem Karan wrote:
In short, you would lose authentication and guarantees of privacy if you
don't have each other's public keys, but it shouldn't affect the
connection in any way, even for anonymous access.
You totally ignore man-in-the-middle attacks, don't you?
Cheers,
-- Ulf
smime.p7s
Zack Weinberg wrote:
In the scenario where the server is authenticated but the client isn't
(initial anonymous pull with the server's public key distributed some
other way, for instance), the man in the middle cannot impersonate the
server, and cannot gain any information that he could not have
[EMAIL PROTECTED] wrote:
I'm sorry I didn't write what I was thinking. :-) I didn't really mean it's
a substitute for channel encryption always. I just meant that it may substitute
connection enrcyption if you're not worried about others knowing that
you store a Monotone database on the server.
Zack Weinberg wrote:
Depends on your threat model. If what you want to guard against is
revealing the content of the database to untrusted parties, then yes,
encryption gives no security if anonymous pulls of the entire database
are allowed. If, however, you don't care about the database
Thomas Keller wrote:
Ulf Ochsenfahrt schrieb:
I looked at those who put their names in the wiki and calculated the
geometric center of that set of points.
Uhh... yeah =)
Theres, three times Wuppertal, once Berlin, once Rostock, once Lübeck.
Rostock and Lübeck make (roughly) two Berlin
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Wed, 25 Oct 2006 22:39:48 +0200, Ulf Ochsenfahrt
[EMAIL PROTECTED] said:
ulf Excepting Richard Levitte, who we'd have to fly in anyway. Are
ulf there any direct flights from Hannover to Stockholm?
I checked how much a ticket
Jeronimo wrote:
On Wed, Oct 25, 2006 at 06:08:04PM -0300, Jeronimo Pellegrini wrote:
That would be O (RSA x users) every time you commit... Is it necessary?
(Or DSA, or whatever other asymetric algorithm)
Just so I write it correctly:
The time would be O ( R x U ) per commit, where
R = time
Nathaniel Smith wrote:
http://venge.net/monotone/wiki/MtnSummit suggests significant interest
in doing this, so, no time like the present... let's see if we can
figure out any more details.
Length: this is perhaps the most important question. How _long_
should this thing be? Two options that
Hi,
I've read most of that thread, and I can't resist posting my opinion. I
like monotone, because it has such a beautifully simple model:
You've got a repository, the repository contains branches and the
branches contain revisions. Each revision has a globally unique
identifier. The
Nathaniel Smith wrote:
On Tue, Oct 17, 2006 at 12:22:24AM -0600, Shaun Jackman wrote:
Hello Richard,
On 10/16/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
monotone-viz is a combination of the net.venge.monotone-viz branch and
debian patches stealthaly snatched from the
Derek Scherger wrote:
When I say team -- share project on the checked out source I select
monotone as the type and it says This project is already a monotone
workspace. Click Finish. When I do this I get An error occurred while
sharing the project: Reason: Invocation of the sharing action failed
on client connections.
Cheers,
-- Ulf
Ulf Ochsenfahrt wrote:
Hi,
I'm sorry, I was in a hurry. Here's the complete bug report:
I was running mtn serve on my server (Debian sarge).
monotone 0.28 (base revision: 8c6ce7cb2ccd21290b435e042c2be4554ec6a048)
Running on : Linux 2.4.27 #1 Mon
Hi,
I'm sorry, I was in a hurry. Here's the complete bug report:
I was running mtn serve on my server (Debian sarge).
monotone 0.28 (base revision: 8c6ce7cb2ccd21290b435e042c2be4554ec6a048)
Running on : Linux 2.4.27 #1 Mon Aug 7 20:11:57 CEST 2006 i686
C++ compiler: GNU C++
Hi all,
The monotone serve command crashes when the connection times out.
Not good.
Cheers,
-- Ulf
--
mtn: fatal: std::runtime_error: network error: recv failure: Connection
timed out
mtn:
mtn: this is almost certainly a bug in monotone.
mtn: please send this error message, the
68 matches
Mail list logo
