Hi all,
There is one failing test on my buildbot at the moment. It is the
database_dump_load
test. Here is the appropriate part of the log:
http://monotone.ca/~mtn-buildbot/ppc-osx104%232/tester_dir.tar
database_dump_load:23: /Users/mtbuildbot/buildslave/full-ppc-
osx104-2/build/mtn
Hi all,
I notice that the current head fails to build the documentation on
MacOS X if you're using the fink package manager for your
dependencies. The problem is that the fink package manager has an
ancient version of gettext (0.14) and its version of xgettext doesn't
handle the
Hi,
First, my apologies for the (lack of) threading - my computer has
died and I'm responding based on reading the list archives.
Markus asked what version of mtn I was using. I noted I updated to
head of the nvm branch last week. Before that I was using a version
from when I set the
Hi,
I awakened briefly to see what was happening with monotone, and
looked at my buildbot to see if it was still ok. It looks like it is
still running, but not succeeding, and few other buildbots are running.
My bot is updating fine, but then failing with the following error:
Hi,
Just one thought about monotone security, which I didn't notice in
your list, but may have missed.
Monotone signs revisions. However, it trusts not just the revision
signed by someone, but all ancestors of that revision as well. This
means that if you can slide a bad change past
On 20/10/2008, at 1:36 PM, Brian May wrote:
William Uther wrote:
Now let's imagine that Bob merges all heads in his database, but
without fully checking Charlie's change. At this point, Bob signs
the newly merged revision.
This is where you need a distributed system for sending trust
Hi all,
I just added rename and delete support for monotone to Ikiwiki. It
is untested. I wont have time to test it any time soon. If someone
feels like testing it soon that would be great.
Things I think need testing:
- Can you get weird effects by conducting renames and
On 20/06/2008, at 2:25 AM, Thomas Keller wrote:
Hi Hendrik!
[EMAIL PROTECTED] schrieb:
sufficient - if of course there is some captcha in-place which
prevents automated patch sending...
If you're going to have a captcha ... I think it's the Univerity of
Illinois library that provides a
On 18/06/2008, at 11:04 PM, Jack Lloyd wrote:
On Thu, Jun 12, 2008 at 05:22:33PM +1000, William Uther wrote:
I have more research to do on git, but as a first pass have I missed
anything someone considers important? (BTW, I don't want to get
into tiny
little details here... I mentioned
On 19/06/2008, at 1:02 PM, Matthew Nicholson wrote:
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
Hi all,
I was looking to do a quick comparison of Monotone and git and just
wanted to make sure I hadn't missed, misunderstood, or misrepresented,
anything (and I know Monotone much better than I know git, so claims
about git are probably where most of my misconceptions will lie). I
On 23/05/2008, at 4:44 PM, Richard Levitte wrote:
willu.mailingLists Note that only when you add a directory with files
willu.mailingLists inside it do you get the warning. The empty
willu.mailingLists directory 'dirB' above doesn't get a warning.
willu.mailingLists (Currently the code
On 23/05/2008, at 5:55 PM, Richard Levitte wrote:
In message [EMAIL PROTECTED] on
Fri, 23 May 2008 17:11:49 +1000, William Uther [EMAIL PROTECTED]
said:
willu.mailingLists Good idea, I like it! However, using
willu.mailingLists directory_empty() can lead to confusion
ooo - yes.
I found myself using mtn log --brief --no-graph file in the Ikiwiki
code. From that I would grab the revs - the hex string at the start of
each line. Then I get the certs on those revs using other automate
commands.
But an automate command like you suggest would be nice. Even
On 22/05/2008, at 11:09 PM, Richard Levitte wrote:
In message [EMAIL PROTECTED] on Thu, 22 May 2008
07:17:05 -0500, Matthew Nicholson [EMAIL PROTECTED] said:
matt Markus Schiltknecht wrote:
matt Yury Polyanskiy wrote:
matt Please consider this bug... It always causes problems when
On 23/05/2008, at 12:52 PM, William Uther wrote:
On 22/05/2008, at 11:09 PM, Richard Levitte wrote:
In message [EMAIL PROTECTED] on Thu, 22 May 2008
07:17:05 -0500, Matthew Nicholson [EMAIL PROTECTED] said:
matt Markus Schiltknecht wrote:
matt Yury Polyanskiy wrote:
matt Please consider
On 09/05/2008, at 9:16 PM, Markus Schiltknecht wrote:
William Uther wrote:
[snip]
Given that, I don't see how you get node I. In that case I would
expect that node I would collect all the changes to node ids 1, 2
or 3. If you have DieDieDie merge, then the fact that you've
killed
On 07/05/2008, at 10:08 PM, Markus Schiltknecht wrote:
Thomas Moschny wrote:
Markus Schiltknecht wrote:
You might even have renames, so that the file to be resurrected
isn't
currently visible. How's the user supposed to resurrect the file
then?
Now I lost you ;) Resurrection is about
On 08/05/2008, at 9:09 PM, 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
On 08/05/2008, at 8:45 PM, Markus Schiltknecht wrote:
A full example, starting from your sample:
A: 1,foo,v B: 2,foo,w
/\ /\
/ \/ \
|\__/\
| / C: 3,foo,x # Alice wants to suture the
| /\
Hi all,
I just committed a branch, net.venge.monotone.simple-resurrect.
This has one revision on it: 7bedf809be5453501c62668a2e00d2a900dc160a .
That revision has a simple file resurrection system, which I think
is the moral equivalent of the 'add, suture' model that is being
On 07/05/2008, at 3:20 PM, Markus Schiltknecht wrote:
i) Keep it symmetric as a delete two, add one operation. In
this case you need to implement some form of merge through suture
ability. e.g. Imagine the following:
o
/ \
a b
/ \ / \
c d e
\ | /
\ |
On 07/05/2008, at 4:57 PM, Thomas Moschny wrote:
The death markings ((ii) from above) can also be easily
reconstructed, but
this would impose a perfomance penalty. That's why we have to think
about way
of also caching that information, be it as part of the roster, or as a
separate
On 08/05/2008, at 7:34 AM, Thomas Moschny wrote:
Hi Markus,
Markus Schiltknecht wrote:
Can you please be more specific? Which three versions of the same
file
are you referring to? I only see two [...]
Ok, here's the graph again. But be warned, we need a lot of
characters ;)
A:
On 06/05/2008, at 5:58 PM, Markus Schiltknecht wrote:
Hi,
William Uther wrote:
I can't see an easy way to implement this without a graveyard. If
you're
going to implement a graveyard, then I'd get rid of DieDieDie merge
first.
Hm.. I don't see what file resurrection has to do
On 07/05/2008, at 5:37 AM, Patrick Georgi wrote:
Am Tue, 6 May 2008 19:54:19 +0200
schrieb Thomas Moschny [EMAIL PROTECTED]:
The problem is, that the all deleted files will have to stay in the
rosters forever. This is not so much a problem storage-wise, because
Couldn't resurrection be done
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
On 05/05/2008, at 4:52 PM, Koen Kooi wrote:
Justin Patrin wrote:
On Sun, May 4, 2008 at 5:29 PM, William Uther
[EMAIL PROTECTED] wrote:
(Aside: was the recent problem OE had with suspend because suspend
itself didn't work, or rather because people were using older
versions
On 05/05/2008, at 6:40 PM, Lapo Luchini wrote:
For those who want to help, the work is currently going on in the
nvm.web.ikiwiki branch. There are some quick instructions in
wiki/ikiwikimigration.mdwn
The base work is kinda finished, the system is working and I did
some massive SED-ing to
On 05/05/2008, at 7:49 PM, Stephen Leake wrote:
Have you considered what happens, if two developers both decide on
merging the files, but a different node-id is choosen? As node ids
are local only, I think you cannot prevent that easily (i.e. by
choosing the lower node id - those might be
On 06/05/2008, at 11:35 AM, Stephen Leake wrote:
William Uther [EMAIL PROTECTED] writes:
If we are truly merging via suturing, nothing is dropped, and
everything is fine. If we are approximating suturing by dropping,
then
this is an issue.
Do you know a way to suture without dropping
On 04/05/2008, at 10:37 PM, Patrick Georgi wrote:
I feel forced in a work flow:
- git-commit --amend is missing
..
- git-rebase -i is missing
These two (at least) change history. Monotone has immutable history,
which is a feature.
(amend-commit as a shortcut to kill_rev_locally, then
On 05/05/2008, at 10:29 AM, William Uther wrote:
On 04/05/2008, at 10:37 PM, Patrick Georgi wrote:
I feel forced in a work flow:
- git-commit --amend is missing
..
- git-rebase -i is missing
These two (at least) change history. Monotone has immutable history,
which is a feature
On 02/05/2008, at 4:46 PM, Graydon Hoare wrote:
The difference in our methods then consists of how these sets are
sync'd. I was thinking of using the revision DAG structure. You
were thinking of introducing a new parallel DAG structure based on
cert creation times. Both use a
On 02/05/2008, at 6:14 PM, Lapo Luchini wrote:
Of course one approach that works for sure is gsync-over-branches
(and sending all of the certs with them as well) and then a merkle-
refinement just to catch up with those few certs that are created
later. I think that such a
On 02/05/2008, at 10:08 AM, Lapo Luchini wrote:
OK. It transfers the DAG oh-so-nice, and cleverly so too.
Yeah - 'tis a cool idea.
Then they told me about the problem with certs: either they are sent
together the rev they refer to at once, or they never get sent later
as the rev is
On 02/05/2008, at 2:59 PM, Graydon Hoare wrote:
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
On 27/04/2008, at 9:58 AM, [EMAIL PROTECTED] wrote:
On Sun, Apr 27, 2008 at 12:39:25AM +0200, Thomas Keller wrote:
The amount of wiki spam gets more and more annoying - do we already
have
something setup like this [0] for our MoinMoin installation?
And, can we somehow easily block
On 24/04/2008, at 4:02 AM, Zack Weinberg wrote:
On Wed, Apr 23, 2008 at 12:19 PM, Koen Kooi
[EMAIL PROTECTED] wrote:
Please ensure that new mtn releases can still talk to 'old'
releases over
netsync, otherwise you are needlessly stabbing people in the eye when
$distro upgrades their mtn
Hi all,
It seems that something has recently broken the build (for non-
linux boxes). The last bit of the failed build looks like this:
if g++ -DLOCALEDIR=\/usr/local/monotone/share/locale\ -
DHAVE_CONFIG_H -I. -I. -I. -I./lua -I./pcre -I/sw/include-g -O2 -
Wall -W -Wno-unused
On 03/04/2008, at 1:11 PM, Timothy Brownawell wrote:
On Wed, 2008-04-02 at 22:16 +1100, William Uther wrote:
Hi all,
It seems that something has recently broken the build (for non-
linux boxes). The last bit of the failed build looks like this:
if g++ -DLOCALEDIR=\/usr/local/monotone
On 15/03/2008, at 9:45 AM, Jack Lloyd wrote:
Certainly, the annotation above could be done with another cert name,
though less conveniently because 'tag' comes with a nice t: selector
syntax.
But you can add new syntax with expand_selector, right? So that part
of it seems relatively low
On 02/03/2008, at 10:58 AM, Anthony Edward Cooper wrote:
We use monotone 0.35 at work and have been having some minor
issues when syncing databases. The problem seems to happen when a
database has a couple of revisions to upload and several hundred
revisions to download (at a minimum).
On 23/02/2008, at 10:56 AM, Brian May wrote:
William == William Uther [EMAIL PROTECTED]
writes:
William Um, syncing to a database is not going to call a hook in
William _MTN/monotonerc either...
I suspect we might be making different assumptions here. Or some other
confusion exists
On 23/02/2008, at 11:50 AM, Brian May wrote:
Brian == Brian May [EMAIL PROTECTED] writes:
Brian - --label, string.format([Yours],
tbl.left_path ),
Brian - --label, string.format([Original],
tbl.anc_path ),
Brian - --label,
On 21/02/2008, at 8:32 PM, Brian May wrote:
William == William Uther [EMAIL PROTECTED]
writes:
Why put the hook into _MTN/mergerc instead of _MTN/monotonerc?
As such, the hook won't get used unless specified. From memory
_MTN/monotonerc is read by default.
William Because
On 21/02/2008, at 10:13 PM, Brian May wrote:
William == William Uther [EMAIL PROTECTED]
writes:
William I just went and had a quick look at the current source.
William In check_mergerc(), why has the mergerc file text been
William split into two places - the main block of text
On 17/02/2008, at 8:08 PM, Brian May wrote:
William == William Uther [EMAIL PROTECTED]
writes:
William I think the Monotone_rcs_support bug got marked as
William closed and it just got forgotten about. I haven't chased
William it up. There is still more work that could be done
On 14/02/2008, at 12:55 AM, Stephen Leake wrote:
Markus Schiltknecht [EMAIL PROTECTED] writes:
Uh.. that would involve tracking the reason for deletion (dropping)
files. Because normally, you want the deletion of a file to be
propagated across merges.
But not if the merge will lose
On 04/02/2008, at 4:32 AM, Julio M. Merino Vidal wrote:
Hello,
I was doing a change to a workspace when I realized that I could
better split it in two different commits. So I checked out a fresh
revision of the single-head I had, made part of the change and
committed it.
Then I went
On 02/02/2008, at 9:53 AM, Zack Weinberg wrote:
You could figure out what the heck to do with the lua_state -
app_state map in lua_hooks.cc? I was going to leave it alone until
everything else was done and then turn it into a lua_state - options
map, but I welcome better ideas. :-)
That
On 03/02/2008, at 9:55 PM, Lapo Luchini wrote:
Zack Weinberg wrote:
I think there might be something else weird with those buildbots.
That test shouldn't use anything like 256MB of memory - in fact,
massif claims it never gets above 10MB (see attached graph). It does
repeatedly allocate and
On 02/02/2008, at 6:42 AM, Zack Weinberg wrote:
Has anyone ever turned persist_passphrase_ok off, and if so, when
and why?
Considering that turning it off means 'mtn commit' will prompt for
your passphrase five times (assuming you type it correctly each time),
which is *terrible* UI, and
Hi,
The BSD buildbots have been failing for a while. This itches. I
don't have any BSD machines, but those builds are the ones that appear
without scrolling to the right on the buildbot page. They're big red
blots on our build record. :) Anyway...
They fail with an out of memory
On 31/01/2008, at 9:58 AM, Zbigniew Zagórski wrote:
I'm hacking silently at mtteam again I hit the wall of safe commit.
Safe means that I'm sure that monotone will not ask anything from
stdin/tty user but fail miserably with some error message. Thus it's
guarantee that it will never hang up.
On 23/01/2008, at 6:20 PM, Brian May wrote:
William == William Uther [EMAIL PROTECTED]
writes:
William http://ikiwiki.info/bugs/Monotone_rcs_support/
This patch is awful.
e.g.
+ #diffurl = http://viewmtn.company.com/revision/diff/span
class=createlinka href=http://ikiwiki.info
On 24/01/2008, at 4:12 PM, Brian May wrote:
William == William Uther [EMAIL PROTECTED]
writes:
William Yup - you need to get the patch from the source of that
page, not the
William ikiwiki munged display version. I've attached it below.
Thanks.
I think I was confused
On 22/01/2008, at 10:00 PM, Stephen Leake wrote:
In my experience, executing mv in the filesystem but _not_ in mtn is
the typical workflow. Then automate inventory reminds you to do mtn
mv.
Interesting. That is the opposite of my experience. I just do mtn mv
as a substitute for mv and
Hi,
I was looking at the same thing. Tailor did not seem a 100%
satisfactory solution, although it could be worse.
I was thinking at one point of using the same idea used in the
cvssync.attrs branch. It would be much easier with subversion.
Basically, you have one micro-branch
On 19/01/2008, at 3:04 AM, Zack Weinberg wrote:
On Jan 18, 2008 5:38 AM, Lapo Luchini [EMAIL PROTECTED] wrote:
We should maybe trade in some security with speed, e.g.
mantaining a
DB table with a cache of valid and not suspended branches.
I'm seriously wondering whether we oughtn't to
On 17/01/2008, at 5:46 PM, Tony Tung wrote:
Well, I run ls branches as part of my shell completion, so 0.2
seconds does seem like an eternity. :) In any case, adding --
ignore-suspend-certs does not make any difference.
Hrm, it appears you are correct. The reason seems to be the
On 17/01/2008, at 8:20 PM, Nathaniel Smith wrote:
On Thu, Jan 17, 2008 at 07:40:09PM +1100, William Uther wrote:
I'm not sure if that should be committed or not. It reduces 'time ls
branches --ignore-suspend-certs' on my monotone db from 7s down to
less than 0.1s. But it means ignoring
On 17/01/2008, at 7:49 PM, Richard Levitte wrote:
willu.mailingLists
willu.mailingLists I'm not sure if that should be committed or not.
willu.mailingLists It reduces 'time ls branches
willu.mailingLists --ignore-suspend-certs' on my monotone db from 7s
willu.mailingLists down to less than
On 18/01/2008, at 7:25 AM, Daniel Carosone wrote:
On Thu, Jan 17, 2008 at 08:36:39PM +1100, William Uther wrote:
B) 'mtn ls branches --ignore-suspend-certs' will behave as
in i).
All branches will be returned, including those with
invalid branch certs - Dr
On 18/01/2008, at 4:15 AM, Zack Weinberg wrote:
On Jan 17, 2008 1:06 AM, William Uther
[EMAIL PROTECTED] wrote:
On 17/01/2008, at 4:00 PM, Zack Weinberg wrote:
While working on something else today I noticed that the suspend-
certs
implementation appears to be doing redundant work. I'm
On 18/01/2008, at 8:59 AM, Zack Weinberg wrote:
On Jan 17, 2008 4:23 PM, William Uther
[EMAIL PROTECTED] wrote:
On 18/01/2008, at 4:15 AM, Zack Weinberg wrote:
update.cc, function calculate_update_set:
...
bool have_non_suspended_rev = false;
for (setrevision_id::const_iterator
On 17/01/2008, at 2:35 PM, Tony Tung wrote:
Hi,
I just downloaded monotone 0.38, and I found the command mtn ls
branches to take a lot longer than the previous version I was
using (0.35). Since I kept the old binary around, I did some
timing with the two binaries, same database. 0.35
On 17/01/2008, at 4:00 PM, Zack Weinberg wrote:
On Jan 16, 2008 11:17 PM, William Uther
[EMAIL PROTECTED] wrote:
On 17/01/2008, at 2:35 PM, Tony Tung wrote:
I just downloaded monotone 0.38, and I found the command mtn ls
branches to take a lot longer than the previous version I was
using
On 16/01/2008, at 3:02 AM, Alvaro Herrera wrote:
Ralf S. Engelschall wrote:
On Tue, Jan 15, 2008, Thomas Moschny wrote:
On Tuesday 15 January 2008, Ralf S. Engelschall wrote:
So, it would be also nice
to have the hunk restriction feature for mtn diff:
$ mtn diff file11:-2,-4
You
On 13/01/2008, at 5:53 PM, Brian May wrote:
Hello,
Just trying to get monotone support in ikiwiki going.
I hacked that up a while back. I got it to the point where I could
use it on my mac with 'web sharing'.
I think there was one patch that never got applied to the ikiwiki
source.
On 13/01/2008, at 10:31 PM, Grahame Bowland wrote:
Hey everyone
ViewMTN 0.08 is out. It's mostly a bugfix release; it includes the
latest web.py (0.22). The main neat new feature is automatic grouping
of branches on the branch listing page, to provide a more concise
listing.
Grab it here:
On 14/01/2008, at 11:17 AM, Roland McGrath wrote:
Is there some reason you left the list out of your message?
Yeah - I found the same thing. The interesting part is that if you
send it through socat then it works... which is how the ssh+ux remote
scheme works - look in the default lua
On 14/01/2008, at 11:18 AM, Thomas Keller wrote:
Stephen Leake schrieb:
So the simple boolean options '--no-unknown' etc won't work with
'automate stdio'.
Changing 'automate stdio' to handle no-value options does not seem
straight-forward.
I'm planning to use '--unknown false', '--ignored
On 14/01/2008, at 1:21 PM, Roland McGrath wrote:
Use the --no-transport-auth option on the server:
mtn serve --bind $HOME/mtnsock --no-transport-auth
That makes no difference the behavior I see.
Hrm. Well, that works for me. I suspect you're not going to get it
going without that
On 14/01/2008, at 1:41 PM, Brian May wrote:
Zack == Zack Weinberg [EMAIL PROTECTED] writes:
Zack If you were interested in improving Monotone.pm to the
point where it
Zack wouldn't be an embarrassment to the archive, I'd be happy
to add a
Zack monotone-perl binary package.
On 14/01/2008, at 1:50 PM, Brian May wrote:
William == William Uther
[EMAIL PROTECTED] writes:
William I think there was one patch that never got applied to
the ikiwiki
William source. It is inline in this page:
William http://ikiwiki.info/bugs/Monotone_rcs_support
On 11/01/2008, at 12:01 PM, Brian May wrote:
Hello
Can I please check my understanding?
I have the following tree:
A1
|\
| \
| \
A2 B2
| |
A3 B3
|
A4
|
A5
At this stage, I realize that the B changes are going to require more
work then I initially anticipated. I would like to move B
On 10/01/2008, at 1:43 AM, Siegfried Herbold wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So, new version of
http://www.venge.net/mtn-wiki/MtnSummit2008
is now available. (I'm back from my winter holiday.)
The room is reserved for us from Apr 28 until May 4.
What we need is
On 06/01/2008, at 3:27 AM, Junqian Gordon Xu wrote:
mtn mkdir foo1
mtn mv foo2/fu foo1
mtn mv foo1 foo3
mtn revert foo3
mtn: fatal: std::logic_error: roster.cc:195: invariant 'inserting
duplicate entry into children' violated
mtn version --full
I tried to replicate this and was unable.
On 20/12/2007, at 11:04 PM, Lapo Luchini wrote:
http://venge.net/mtn-wiki/MtnSummit2008
Just to remind everyone that the Summit is not something only the 3-4
big-developers can and should attend to.
As the page states:
Our bar is strict but low: if you're willing to work, you're
welcome
On 18/12/2007, at 12:58 AM, Nathaniel Smith wrote:
On Mon, Dec 17, 2007 at 06:15:11PM +1100, Brian May wrote:
Timothy == Timothy Brownawell [EMAIL PROTECTED] writes:
if a directory already exists, so what? presume it was already
added by a incomplete update and continue
Timothy
On 27/11/2007, at 7:17 AM, Benjamin Place wrote:
I'm trying to propagate some changes between two branches, and I'm
getting:
mtn: warning: resolve non-content conflicts and then try again.
mtn: error: merge failed due to unresolved conflicts
mtn: warning: rename target conflict:
On 18/11/2007, at 6:46 PM, Jack Lloyd wrote:
On Sun, Nov 18, 2007 at 06:20:08PM +1100, William Uther wrote:
If you're going to have the key show up as [EMAIL PROTECTED]1 and
[EMAIL PROTECTED] 2 when there are multiple keys, why not just
make the
user genkey [EMAIL PROTECTED] 2 when
Hi,
I have a quick question about deterministic mark merge. I'm a
little confused about when something is decided to be a conflict. In
particular, how would the following examples work out?
I've put ?s on the nodes that I'm interested in.
a*b* c*
\ / |
\ /
On 19/11/2007, at 3:37 AM, Timothy Brownawell wrote:
a*1 b*2 c*3
\ / |
\ / |
{a,b}4 |
/ \/
/ \ /
c*5 {a,b,c}6
\ /
\ /
c7
The mark sets here all have the same nodes as before. But this time,
the
On 19/11/2007, at 5:07 AM, Stephen Leake wrote:
Lapo Luchini [EMAIL PROTECTED] writes:
Richard Levitte wrote:
I won't deny that William's change is going to make a difference,
but
I question if it will be *enough* of a difference.
IMHO as creation of more keys with same name will
Hi all,
A while back there was a complaint on the mailing list that
monotone was ignoring changed content. This was happening when there
were content changes on one side of a merge, and the same node was
dropped on the other side of the merge. In this case Monotone would
silently
... has some somewhat out of date hooks it seems: :)
function get_post_targets(groupname)
return { nntp://127.0.0.1:8119/monotone.test.packets; }
end
function get_fetch_sources(groupname)
return { nntp://127.0.0.1:8119/monotone.test.packets; }
end
function
On 06/11/2007, at 10:25 AM, Graydon Hoare wrote:
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...),
On 15/11/2007, at 7:49 PM, Markus Schiltknecht wrote:
Hey William,
William Uther wrote:
As a first step I'd like to make a version of monotone that
remembers the new 'existence' marks when the file exists (i.e. add
existence marks to the current code without trying to remember them
On 16/11/2007, at 12:17 AM, Markus Schiltknecht wrote:
Hi,
William Uther wrote:
(which does not track merges). And try to get merging right for it.
Um, if it does not track merges, how do you get merging right?
Sorry, I was unclear here. There are two different cases: one is the
sync
On 16/11/2007, at 8:17 AM, Graydon Hoare wrote:
I would not worry, in general, about the persistence of ghosts or
trimming their marks from the roster.
Fir my first pass, that is exactly my approach. This is tricky enough
code as it is, and it isn't an area where you want to make
On 15/11/2007, at 11:58 PM, 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
On 16/11/2007, at 9:48 AM, William Uther wrote:
A point you have to be sure to address throughout the tool is that
you have to modify things that detect conflicting nodes by path,
since paths can only have a unique *live* occupant. Change it such
that eg. a/b/foo.txt and a/b/foo.txt only
Hi,
I'm looking at how to get rid of die-die-die merge for files. As
noted by others, if we used mark-merge here then we'd be able to un-
delete and re-delete, and everything would just work.
As a first step I'd like to make a version of monotone that
remembers the new 'existence'
On 13/11/2007, at 10:35 PM, Ralf S. Engelschall wrote:
I have no idea why the file:// URL would be failing (other than on
Windows). This is tested for in
the unit test netsync_over_pipes. What platform are you running
on? Is
the db you're pulling from local, or on some file server?
It
On 12/11/2007, at 7:19 PM, Ralf S. Engelschall wrote:
It seems that the 'mtn pull' part is freezing. The first thing I
would
check is if the commands work individually. Can you execute these
three commands:
mtn db init --db=local.db
mtn pull --db=local.db
On 11/11/2007, at 8:57 PM, Ralf S. Engelschall wrote:
I tried to use mtn clone, but in all my tests it hangs endless:
| $ /usr/opkg/bin/mtn clone -b FreeBSD.snapshot.src file:///v/freebsd/web/x/freebsd-snapshot.db
y
| mtn: setting default server to
On 12/11/2007, at 2:48 PM, Derek Scherger wrote:
After a brief chat on irc today I was left with the following
impressions as to where this might go.
- remove -b from commit (Thomas Keller already has this done)
- add a mtn branch command for creating new branches that sets the
workspace
I'm happy with any and all my monotone contributions under the GPL v2
or GFDL (including contributions to monotone.texi) being released
under the GPL v2 or later.
Be well,
Will :-}
On 09/11/2007, at 4:10 PM, Zack Weinberg wrote:
In February, Nathaniel requested that all
1 - 100 of 263 matches
Mail list logo
