It appears that there are status values in the 'automate inventory'
command for unknown/missing files.
Does automate actually generate these values?
Getting a list of everything not under cm control is really useful
Joel
On 2/23/07, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Fri, Feb 23,
Hi all,
Here's another patch. This one implements mtn clone and some tests.
% ./mtn help clone
[snip]
Options specific to 'mtn clone':
--branch [ -b ] argselect branch cert for operation
--exclude arg leave out anything described by its argument
--revision [ -r ] arg
Hi!
I'm using monotone-0.32 from pkgsrc on NetBSD-4.99.11/amd64.
I was running 'mtn ls unknown' on a dir where a subdirectory had
a symlink loop (i.e. foo/bar/baz links back to foo). 'mtn ls
unknown' took a long time and then complained about too many levels
of symbolic links. So far, so good.
On 24/02/2007, at 9:30 PM, William Uther wrote:
Hi all,
Here's another patch. This one implements mtn clone and some tests.
- It doesn't clean up in some failure situations. I made it fail
if the destination dir exists, so it is just a matter of catching
any failures and removing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK. I'm probably paranoid.
But I always end up sync'ing to:
{net.venge.monotone,net.venge.monotone.*}
mainly to avoid the hypotetical and currently non-existing
net.venge.monotone-sucks branch, which is of course included
by the usually suggested
On Saturday, 24. February 2007, Thomas Klausner wrote:
However, since then I can't use 'mtn ls unknown', it fails with a
violated invariant. 'mtn db check' is happy.
Iirc, this is an annoying bug in 0.32 that was already fixed on mainline and
thus will not be there in the upcoming 0.33
On Saturday, 24. February 2007, Lapo Luchini wrote:
But I always end up sync'ing to:
{net.venge.monotone,net.venge.monotone.*}
[...]
Anyone has simpler solution to the aforementioned problem?
While I am not sure I understand the real problem, I observed that the
obvious variant doesn't work:
On 2/24/07, Lapo Luchini [EMAIL PROTECTED] wrote:
Should we need an operator that means either nothing or .something?
Anyone has simpler solution to the aforementioned problem?
Here's an idea. Make it work like DNS:
net.venge.monotone = net.venge.monotone.
and also that * can match the empty
I have two separate projects that I manage with monotone.
When I run mtn sync from a checkout, what I expect is for the
current branch to be synced. What actually happens is it syncs some
(set default?) branch so I have to pass the host name explicitly. If
I switch with --set-default, then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Evan Martin wrote:
Here's an idea. Make it work like DNS:
net.venge.monotone = net.venge.monotone.
and also that * can match the empty string (maybe it does already?)
and then net.venge.monotone.* would do the right thing.
There's some
On Sat, Feb 24, 2007 at 07:57:34PM +0100, Thomas Klausner wrote:
On Sat, Feb 24, 2007 at 04:53:30PM +0100, Thomas Moschny wrote:
Iirc, this is an annoying bug in 0.32 that was already fixed on mainline
and
thus will not be there in the upcoming 0.33 release.
Can you please point me to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Evan Martin wrote:
Am I doing something wrong here, or is this expected behavior? (In the
latter case, is it desirable?)
It is in fact expected (whether it is desirable or not, is debatable).
The best way to go depends on your use case:
a.
On Sat, Feb 24, 2007 at 03:06:59PM +0100, Lapo Luchini wrote:
OK. I'm probably paranoid.
But I always end up sync'ing to:
{net.venge.monotone,net.venge.monotone.*}
mainly to avoid the hypotetical and currently non-existing
net.venge.monotone-sucks branch, which is of course included
by the
On 2/24/07, Evan Martin [EMAIL PROTECTED] wrote:
I have two separate projects that I manage with monotone.
When I run mtn sync from a checkout, what I expect is for the
current branch to be synced. What actually happens is it syncs some
(set default?) branch so I have to pass the host name
On 23/02/2007, at 10:08 PM, Richard Levitte - VMS Whacker wrote:
Hi,
I've currently two tests failing:
326 restrictions_with_renames_and_addsFAIL (line 37)
416 ws_ops_with_wrong_node_type FAIL (line 19)
Test 326 shows that a revert will not necessarely remove
Hi all,
I've just finished a patch to make --execute the default.
Actually, it entirely removes the --execute option, and adds a new
option --bookkeep-only which is approximately the inverse of -e.
This also adds some checks to the drop implementation so that if you
try to drop a
16 matches
Mail list logo
