Richard Levitte wrote:
Now, the bigger question is, who has control over monotone.ca again?
The current IP address, 217.25.36.66, needs to be changed to
62.20.50.66.
I do, and have now changed the DNS to reflect this. Hope you meant it :)
-Graydon
Lapo Luchini wrote:
Bruce Stephens wrote:
It used to store the binary deltas in base64, IIRC. (Just an
implementation detail, in other words.)
OK, but that's only because SQLite2 had problems with \0 most probably,
and has nothing to do with the actual content of committed files; on the
William Uther wrote:
Hrm. I certainly didn't give it a huge amount of thought. My disquiet
stemmed from the fact that the cert creation time information is mixed
up in this new cert DAG.
Sure, the cert DAG winds up reflecting the mixture of the structure of
the revision graph and the
Lapo Luchini wrote:
Reading William's and Graydon's answers, I'm not sure I perfectly
understood their proposal and why it doesn't have the same problem as
mine. Graydon, what's the relation between your synthetic tree file and
branches?
I'm assuming you're asking what the formal connection
William Uther wrote:
Yeah - Graydon had a plan for this I thought. It vaguely sounded
similar to yours, with some differences in details. From memory it was
something like: build a separate tree of certs based on time of cert
creation, and sync it using the same nuskool algorithm.
While I
Graydon Hoare wrote:
My plan here was to rip out netsync, packets, basic_io, netio, and the
old cert system. Put in the new cert system and the new sync system, and
replace the automate commands with json-speaking equivalents. Do away
with all the legacy i/o stuff, and provide one that's
Thomas Moschny wrote:
On Monday 28 January 2008, Graydon Hoare wrote:
I think it's a good branch as they go in this sort of thing. I just ran
out of interest.
Sorry to hear that, but that's life, it seems.
It contains a variety of interrelated new code. Anyone
else is welcome to pick it up
Thomas Keller wrote:
You've probably read Graydons recent message; I did and I have to say
that it made me a little sad. Not because Graydon officially stopped
working on the project - he wasn't doing many things lately anyways
beside the recent attempt of redoing netsync with something
Hi,
I haven't posted here in ages, and it doesn't really matter given my
minimal contributions recently, but I feel a personal connection to this
project and the people who've helped over the years, so I figured I
ought to post a quick, formal note about ending my work on it.
Since the
Matt Johnston wrote:
On Thu, Nov 15, 2007 at 09:57:50AM +0100, Markus Schiltknecht wrote:
You've read and understand *-merge? Best sources here [1]. Can you
expand on you concept of 'existince marks'?
Existence marks already exist for attrs don't they - the
difference being that attrs aren't
Chad Walstrom wrote:
Jack Lloyd [EMAIL PROTECTED] wrote:
What if keys were versioned, so multiple keys with id
'[EMAIL PROTECTED]' show up in displays as '[EMAIL PROTECTED]1',
'[EMAIL PROTECTED]2', ...
Or '[EMAIL PROTECTED](ah6821h...), [EMAIL PROTECTED](eybn861...)'.
Rather than enumerate
Markus Schiltknecht wrote:
Dear monotone hackers,
I'm happy to announce that I've recently signed a contract with
MQSoftware, who sponsors me for finishing my cvs_import rewrite. I wish
to thank Kelly F. Hickel for making this possible, and I'm looking
forward to contribute to their and
Alvaro Herrera wrote:
Markus Schiltknecht wrote:
Hi Markus,
To make things even worse, all the links to papers cited in differ.scm are
not valid anymore ([2] and [3]). And google didn't turn up anything useful
either.
This paper is here:
http://www.cs.arizona.edu/~gene/PAPERS/np_diff.ps
Bruce Stephens wrote:
Right, so this is the same idea as nested checkouts, but using the
manifest rather than some other mechanism?
We've batted around the shape and texture of this for years, but nobody
ever pushed on it hard enough to implement. It's one of those broad yet
shallow UI
Richard Levitte wrote:
Finally, monotone 0.36 has arrived. There are quite a number of
changes and corrections in this release, well worth investigating.
Take a closer look at http://monotone.ca/
Fri Aug 3 06:08:36 UTC 2007
0.36 release.
Changes
... long list of lovely
Richard Levitte wrote:
Aha! *cracks knuckles* S, if someone would listen to you saying
bug, probably for the umpteenth time, and get the idea of actually
doing something about it, you wouldn't mind, would you?
Haha, not in the least. I wish I could dedicate a doppelganger of myself
to
Richard Levitte wrote:
Actually, the reason that key IDs must be unique is that the table
that stores them is indexed by, you guessed it, unique key IDs. To
this day, I still can't understand that decision, it has created more
problems than it has solved, as far as I can see. The key table
Markus Schiltknecht wrote:
What I'm wondering is... can monotone's approach represent some
situation that git cannot?
Hm. Good question. I guess it's a matter of taste, if you want the VCS
to provide shared branch names or if you are fine with relying on
everybody naming his local branches
Thomas Moschny wrote:
Having combined certs would solve that problem at the cost of sometimes
storing the same information twice: e.g. when two people do the same merge,
there will be two certs with different dates/authors, but identical branch
names and commit messages. But that's reasonable
Justin Patrin wrote:
One thing
Linus mentions in the talk is that a function moving from one file to
another would be recognized by annotate because of the fact/way that git
tracks content. This sounds interesting and I'm curious as to what it
looks like in practice.
In practice it's
Nuno Lucas wrote:
Maybe I got this wrong, but based on what I have seen so far of this
talk, I couldn't help but think that Linus didn't consult the Monotone
developers with his concerns about speed, why it was slow, or how much
work it would take to improve its speed.
He talked to us a bit.
Bruce Stephens wrote:
I note that they say:
Monotone was ruled out relatively early as well, due to the
similar [to git] Win32 performance issues and not wanting to split
developer resources with Monotone fix- and feature-requests.
Does anyone know what the win32 performance issues
William Uther wrote:
mtn: warning: ignoring bad signature by
'[EMAIL PROTECTED]' on
'[EMAIL PROTECTED]:YXUuY29tLm5pY3RhLmRnYw==]'
I was hoping that the bad rev would eventually be ignored once
evveryone moved past it, but I just checked out a new workspace, and
it gave that warning too.
Evan Martin wrote:
The browse source link isn't a 404 but it also isn't useful because
there's a million branches in that viewmtn.
Finally, mailing list and logs are in both the middle and
rightmost columns. Maybe that's intentional.
Yeah, the website is in flux. Sorry. It's moving from one
Zack Weinberg wrote:
Does anyone have (good) reasons not to do this? I think it'd help us
keep the code clean.
I tried to do this once before. I found some real, if probably
harmless, bugs doing it (things being converted to types they honestly
weren't) and I think it's a great idea, but I
Boris wrote:
What happens if a user who has only read-permission for branch A writes
something to branch B? As far as I see this is possible as
write-permissions are per database and not per branch. If branch B is
only for privileged users is it still protected? I'd say so as the new
user
Zack Weinberg wrote:
I just pushed a change that removes transforms.cc's bespoke
implementation of hex encoding in favor of Botan's. I believe this to
have been a historical accident, but if it turns out to cause
performance issues (which I doubt it will) we can certainly go back to
the way it
Nathaniel Smith wrote:
On Mon, Nov 27, 2006 at 08:38:49PM +0100, Markus Schiltknecht wrote:
Hi,
I've found the bug: I've added a '--verbose' flag, which seems
deprecated. Sorry for the noise.
--verbose is totally warty (right now it means use a randomly
different output format when doing
Thomas Keller wrote:
Please have a look at the attached patch. I have to excuse that there
are some unrelated changes in this patch (basically renaming of an
automate test to better fit the automate command and some formatting
fixes in monotone.texi) - this won't happen again.
If everything
Markus Schiltknecht wrote:
Complete? Is there a beginning?
Not that I'm aware of, but I hardly manage to keep up with the NEWS file
these days, much less all the material on side branches.
Why a special port? Can't this be part of netsync?
I meant that we could add support to a special
Matthew A. Nicholson wrote:
boost::asio (http://asio.sf.net to be included in the next version,
probably coming out in may) handles this quite well.
Yeah, we've seen asio and sort of considered it off and on for a while.
I'm of mixed opinions on the matter:
- On the one hand, it'd be
Christof Petig wrote:
I would rather complete partial pull for monotone than to start coding a
cvs server (or porting git-cvsserver). I have suffered from CVS protocol
variations on the client side enough for this life! ;-)
Fair enough. I think actually the way I'd want to do this is in a few
Dan Ginsberg wrote:
If I blow away the client db and, init a new db and do a fresh pull,
then I'm fine. But if i try to sync using the old db it errors and
crashes the server. Reproducably fine with new db and reproducable
netsync.cc error with old db.
It sounds vaguely like SHA1 has
Nathaniel Smith wrote:
Check out git-cvsserver.pl, which exposes a read/write (!) interface
to a git repo through the pserver protocol...
It's not so horrible as it sounds because you get to use the sane,
non-CVS model internally; the semantics are reasonably
straightforward. The painful part
Justin Patrin wrote:
Yes, but shouldn't monotone by default ask for a comment for
disapprovals? I've also found this to be somewhat unintuitive and
unhelpful default behavior...
Yeah. It'd be good if it took a message.
I'm hoping when we get around to overhauling the cert format --
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
Jon Smirl wrote:
There is a large discussion happening on the git mailing list
comparing the internals of various SCMs. Monotone developers might
find it interesting.
http://thread.gmane.org/gmane.comp.version-control.git/28881/focus=28881
Oh dear, what a tiring thread!
Each of the tools
Markus Schiltknecht wrote:
It's still experimental code, though. I have not implemented splitting
of blobs nor tags, so other test cases fail. But switching to using
blobs of cvs events has been done. Now, during parsing of the RCS files,
all cvs events are collected in blobs, depending only
Markus Schiltknecht wrote:
I'm all for that very self-critical point of view. But I've seen the
'this most probably is a bug in monotone' message ways too often in
cases where monotone wasn't to blame at all. I know it's hard to always
provide good error messages... but one should always try
Nathaniel Smith wrote:
It isn't too complicated, though, and the python-ness isn't important;
the important part is the disk format. Ideally we'll even move it
into montone proper at some point (anyone know where to get a decent
C++ HTTP library with pipelining support?).
I don't know about
Koen Kooi wrote:
I still think monotone is the best open-source VCS/SCM around, but I am a bit
dissapointed
at 'history digging' tools and their performance. And more recently in 'mtn
add' and 'mtn
diff' being broken by the IMO bogus restriction code. So I'm wondering, is
there a plan to
fix
Justin Patrin wrote:
Basically what I'm saying. I suppose, is that there need to be
policies/permissions both for updating and for netsync.
In my mind there is no question about this. We must store netsync
permissions as well; a file-sharing server is a real, physical resource.
It needs
Bruce Stephens wrote:
More than that: that's an important feature, not a bug. I shouldn't
be prevented from committing to a tree just because its owners haven't
(currently) allowed me to.
So is there something you aren't describing, to do with how all this
gets enforced?
Enforcement is
Thomas Keller wrote:
Here are the top 3:
1) monotone.ca (35)
Ok, I've bought this domain now. There is some DNS cache-reload time and
whatnot, so it might not show up immediately. Plus I might have
misconfigured it. I'll just point it to the same place when it comes
online. Should be
Derek Scherger wrote:
Yeah, my vote goes for monotone.ca.
Did you check on monotone.net? It seems to be registered and held but
not being used for anything useful. I wonder if there's a possibility we
could get that? And even if we could, I'm not sure it's any better than
monotone.ca.
I
Nathaniel Smith wrote:
The change is very large -- 32 files changed, 2387 insertions(+), 1073
deletions(-) -- and messes about with some very important pieces. In
particular, if there are bugs in roster reconstruction, that could
jeopardize our sanity checking generally. So, I'd really
Timothy Brownawell wrote:
Won't these be somewhat non-portable, such as to windows? I thought
monotone proper (as opposed to, say, extensions you can put in
monotonerc) was supposed to be the same on all platforms, are we
loosening that?
I don't think I've ever really stated much of a strong
Timothy Brownawell wrote:
nvm.experiment.boost-program-options works now, and I think it's ready
for mainline. The only visible change (at least, the only change noticed
by the testsuite) is that --option= doesn't work any more; --option
'' is still fine. This appears to be a misfeature in
Eric Anderson wrote:
My best guess was that widen was there to make sure that when widening
a signed to an unsigned the right thing happened, but I wasn't sure it
seemed unnecessary for an unsigned to unsigned widen.
Yup.
The main part of the function actually is the implicitly convert to
Nathaniel Smith wrote:
Please send a patch! :-) Probably the right syntax to use is
ssh://[EMAIL PROTECTED]/~/path/relative/to/home
which is the syntax that the bzr folks converged on after a bunch of
fuss and bother.
Or ssh://[EMAIL PROTECTED]:home/relative/path, like scp uses. It's
Eric Anderson wrote:
I see a number of possible solutions:
1) write a custom string allocation system that runs without locks and
modify all of the string stuff to use that. Very ugly, but possibly
made easier by the use of the vocab wrappers.
See quick_alloc.hh. The idea was
Bruce Stephens wrote:
And (obviously) maybe a VCS could use some kind of similar idea,
rather than trust always being binary.
So maybe when I do mtn update, I could give some indication of how
lucky I feel, and then mtn could choose a revision that's either
completely tested and signed by
alex ku wrote:
- I found Monotone, but got stuck at the point where I seemingly need to
have a server setup.
If you can both access the same shared ssh account, perhaps you can use
the new sync URI argument syntax:
mtn sync ssh://our.shared.host.com/path/to/db.mtn com.us.somebranch
Zack Weinberg wrote:
See if you can reproduce at -O0. -O3 most definitely *is* an extreme
optimization setting[1], and I'm pretty sure we have
-fno-strict-aliasing in the default CFLAGS for a reason. [I don't
know what it is, though, and I was wondering if it could be taken out
myself...]
Thomas Keller wrote:
Sounds cool. Of course, trac would need monotone support for this to
work and it would have to be maintained as monotone changes and
matures further
Thomas Moschny is the author of TracMonotone
http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone/
Ah, nice. Well,
Zack Weinberg wrote:
To be clear, my primary motivation for the original patch was a worry
that two places in the source code might decide to hard-code the
*same* fake hash, and that they would then somehow collide. (I think
that in all of the places that currently use fake hashes, this can't
Nathaniel Smith wrote:
Well, as Zack mentioned, it is rather a pain to pass that database
handle around everywhere (and it would be nice to pass it less
places!). Furthermore, there are times when you don't really mean
that anyway -- e.g., in the pluck code, I use 3 fake rids (for marking
the
Nathaniel Smith wrote:
I don't quite follow this part. Above you seemed to say we would just
re-code the contents of revisions into db rows; but revisions contain
no information that lets you skip between revs that actually affect
a given file. I guess you store some more information than
Eric Anderson wrote:
Any guess as to how difficult that would be? Given your description,
I don't think I would be qualified to make the change. If it would
take a while to make this change, is it worth transitioning through a
relatively ugly hack to make it tolerably fast while work on the
Zack Weinberg wrote:
There are a small number of places that need a fake ID of some variety
(ignoring all the unit tests, which use 'em heavily) and we currently
just pick a random 160-bit number. I need to add a few more of
these, so I thought it would be a good idea to have a principled way
Jack Lloyd wrote:
On Tue, Jul 18, 2006 at 05:24:08PM -0700, Graydon Hoare wrote:
It's easy enough to start with the all zero SHA1 and count upwards.
It's probably even fine if you just run through the first 2^64 of them
for now; you can't store anywhere near that much data in an sqlite
Nathaniel Smith wrote:
If we don't trust SHA1, why are we using it at all? :-)
I do trust SHA1, at least as far as it goes. I don't see how that's
related to hard-coding a target for it to collide against when you have
a simple means of picking a value you *know* is non-colliding.
If we
Thomas Haas wrote:
I am using motone 0.27 Cygwin on Windows XP.
The creation date (ls -l) on files checked out (using mtn checkout or
mtn revert) is set to the current time. My expectation is the creation
date on files being the same after checkout (or revert) as during commit.
What is the
Rob Schoening wrote:
I have a somewhat unrelated question that touches on a more fundamental
security issue:
what is the relative security risk of running netsync on a public port
assuming it's running as a non privileged user? how much of a
vulnerability is it for the host that's serving
Nathaniel Smith wrote:
I just landed on mainline my branch to add a 'mtn pluck' command; it
lets you pluck some changes from an arbitrary place in history, and
drop them into your workspace. I.e., basic cherrypicking support --
none of the fancy tracking stuff that a true cherrypicker, like
Hi,
I just tracked down a subtle and annoying netsync bug that has been
pestering us for a while. It involves a not-very-hard-to-trigger case
wherein the nesting of queries and subqueries gets broken. The symptom
is just netsync going dead awaiting i/o, with no obvious logic errors or
data
Bruce Stephens wrote:
By the first, do you mean you want to revert the changes in one file
from a revision, while keeping the rest?
It's true that you can't directly do that
It wouldn't be terribly hard to add. The current disapprove code works
by committing a change that undoes the edge
Derek Scherger wrote:
In svn, for example, branches have a lifetime like any other node in the
tree (since they are represented as tree nodes) which makes it possible
to create a branch, work on it for a while and then delete it when
you're done.
Thoughts?
Yeah, certainly I've been thinking
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Tue, 13 Jun 2006 07:58:06 +0200 (CEST), Richard
Levitte - VMS Whacker [EMAIL PROTECTED] said:
richard My next try will be to take the regular mtn head (nvm) and
richard see if that makes a difference.
It did. Weird, there's
Nathaniel Smith wrote:
We all definitely agree that (0) is fine, and that (6) is not.
Therefore, we probably each have some first number that we think would
be unacceptable. When you say Don't do it, do you mean that for
you, the line of acceptability falls between (0) and (1), (1) is
already
Nathaniel Smith wrote:
If you made it this far, thanks for reading :-). I'll probably start
implementing this in the next few weeks (assuming that the response to
this isn't an overwhelming this would be a horrible violation and
can't be done at all!), but really want to make sure that we get
Nathaniel Smith wrote:
On Sun, Jun 04, 2006 at 10:17:50PM -0500, Timothy Brownawell wrote:
Why do we need to hide boost::format? Should we just use extern
template for our % and make having an instantiation of that be another
requirement for types we want to format, along with having an
Thomas Keller wrote:
Check: http://thomaskeller.biz/stuff
I actually rather like the existing logo, and have no real desire to
change it, except that I found out that we really ought to purge
ourselves of the existing one since it's derived from an image we don't
hold a license for. So
Thomas Keller wrote:
Wow... now this does look pretty similar to a naked mole rat (no tail?)
Nah, naked mole rats look different. Blind, wrinkly, large curved
protruding teeth. Not especially pretty. Alex's tail is just hidden by
the camera angle.
Would you mind and share the svg
Richard Levitte - VMS Whacker wrote:
lapo IMHO the data stream should contain uncompressed data and be
lapo compressed at the stream level.
Exactly.
I agree that you'll probably win by doing full stream compression. I'll
offer a couple points in my defense to explain why I did it this way.
Nathaniel Smith wrote:
Plus it's totally non-streamable :-). You'd basically end up doing
exactly what we do now, since bzip2 operates on blocks (hence the
b)...
Eh, I'm not sure I really agree with this interpretation. As far as I
know, most compressors operate on (possibly padded) blocks;
Timothy Brownawell wrote:
Netsync (initial pull, counting both server and client) appears to be:
13% libz (56% compression + 22% decompression + housekeeping)
11% Botan::SHA_160::hash
It's important to differentiate two classes of gzip and sha1 here. There
is a portion we do on the
Graydon Hoare wrote:
We can give up the gzip on either without much hassle: on the protocol
stream it'll just result in more overall transmission (which is probably
OK since we're not near wire speed yet) and on the database it'll mean
more database storage allocated, which might be ok
Chad Walstrom wrote:
Justin Patrin [EMAIL PROTECTED] wrote:
*18*? Wow, that's a bit behind the times. A lot has changed.
It's not so hard to imagine. For example, Debian stable ships with
Monotone 0.18, and some people are happy working with packages only
found in the stable release of
Joe Wilson wrote:
I noticed a recent post on the SQLite mailing list
(http://www.mail-archive.com/sqlite-users%40sqlite.org/msg12839.html) asking
how monotone might
speed up its database access. Two simple optimizations that come to mind are:
(1) Use a larger default SQLite page size and/or
Michael Milner wrote:
Hi,
I've been following along on recent developments and am very pleased with
the stability of 0.26rc1.
Is there currently any kind of roadmap to the first stable release?
I've been using monotone extensively for some small projects with great
success, but I am a bit
David Hoke wrote:
monotone commit --message=version 2 of file 1
cd ..\workingcopy2
***Note this point
monotone status
monotone diff
type file1.txt
monotone update
type file1.txt
---
At the ***Note this point*** point, I would expect a difference
Markus Schiltknecht wrote:
what's up with the cvs_import rewrite branches? Anybody still working on
such a thing?
I completed the branch and merged it back to mainline, quite a while ago.
cvs2svn uses a multiple passes of processing the cvs repository.
Yes. The .rewrites.cvs_import branch
graydon hoare wrote:
(Several people have asked for a public cafepress shop they can purchase such a
thing from -- even if they don't fix any bugs -- so I'll set one up shortly)
We now have such a thing: http://www.cafepress.com/monotone_vcs
The bugathon is going very well so far
Joe Hull wrote:
I believe I'm observing that when monotone successfully completes an
internal three-way merge the resulting merged file always uses a LF as
its line ending no matter what the line ending convention of the host
system or the line endings of the three source files for the three-way
Christof Petig christof at petig-baender.de writes:
After some strange but legal criss cross merging yesterday, monotone
refused its work with the following error:
monotone: fatal: std::runtime_error: cycle in table 'manifest_deltas',
at node b4c5672e5c1a1749b6cf4eb78165e18e6480ff67 -
graydon hoare graydon at pobox.com writes:
The solution is relatively easy and I've applied it to the mainline today: now
the reconstruction algorithm understands DAGs in the storage graph. Please,
everyone who has picked up a propagate from the mainline since 2005-11-05,
propagate the change
Bruce Stephens monotone at cenderis.demon.co.uk writes:
Let me guess, an attractive logo in white on a white T-shirt?
It's a shirt containing the monotone logo, of course.
(Several people have asked for a public cafepress shop they can purchase such a
thing from -- even if they don't fix any
Hi,
We've been discussing on IRC having a little big-squashing party this
weekend, to finish up the roster branch and clean out as much cruft
from the BTS as possible. I'm going to try to close as many of the
remaining roster testsuite failures as I can before then. We're down
to 29 or so failing
Hi,
I understand your concern, but I think you're over-stating the problem
(or failing to note the slow direction we're already moving in).
Internally, most of monotone's text formats are converging to a single
style: basic_io. Contrary to what you've suggested, whitespace is not
significant in
On 10/4/05, Nathaniel Smith [EMAIL PROTECTED] wrote:
Using a db var in next_node_id makes me vaguely queasy; having a
command line way to totally corrupt your db seems bad? Maybe I'm
being a fussbudget.
Makes me queasy too. I did it that way because it was easy and didn't
involve making a
In gmane.comp.version-control.monotone.devel, you wrote:
(personally, I wouldn't have made monotone depend on the keyid, but
hey, I'm not the original author)
this is a bit of a tradeoff. on the one hand, using the key hashes
means you can probably rename keys and at very least put up with
hi,
I've posted some work I started on while on vacation to
net.venge.monotone.rewrites.change_set (and cvs_import). these are
sandbox branches I'll be merging in once I'm confident in their
functionality (and, of course, depending on how much complaint I get
from others). each addresses a
On 6/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Some good looking changes here. Can you clarify the 'supporting explicit
directories' a bit - sounds useful!
directories will be stored in manifests, by name. you can store empty
directories. there will be an add_directory event, to
rghetta birrachiara at tin.it writes:
If anyone is interested, attached is a (small) screenshot of an older
release of gitk more or less working with monotone.
The similarities beetween git and monotone are enough to make even this
brutal hack work, though not completely.
very nice! could we
95 matches
Mail list logo
