On Thu, Sep 20, 2007 at 01:42:48PM +0200, Ralf S. Engelschall wrote:
> For your information: as Joe Wilson discovered (and I was able to
> verify it) the problem is that Monotone still uses SQLite 3.4.2 while
> my sqlite3(1) above was already from SQLite 3.5.0 The difference
> is in the compile-tim
On 9/20/07, Thomas Moschny <[EMAIL PROTECTED]> wrote:
> On Thursday 20 September 2007, Richard Levitte wrote:
> > However, if that's good enough, you can use 'mtn list changed' and see
> > if it outputs any lines.
>
> You could check, whether the manifest has changed, i.e. whether these two
> outpu
On Thursday 20 September 2007, Richard Levitte wrote:
> However, if that's good enough, you can use 'mtn list changed' and see
> if it outputs any lines.
You could check, whether the manifest has changed, i.e. whether these two
outputs are the same:
$ mtn automate get_base_revision_id | mtn auto
On 9/20/07, Richard Levitte <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> on Thu, 20 Sep 2007 15:42:42 +0200, Thomas
> Keller <[EMAIL PROTECTED]> said:
> me> So, the only way (currently) to determine if the current workspace
> me> has changes or not, is to look at the output of mtn a
Richard Levitte schrieb:
> Please check the facts before you say something:
Umm... sorry. Indeed, you're right. I was way mislead by cat
_MTN/revision. Anyways, this is one more reason for an automate function
to return this info properly, or even better, for copying over mtn ls
into automate and
In message <[EMAIL PROTECTED]> on Thu, 20 Sep 2007 15:42:42 +0200, Thomas
Keller <[EMAIL PROTECTED]> said:
me> Nuno Lucas schrieb:
me> > The problem is that if there are no changes to the working space,
me> > get_current_revision_id outputs some "bogus" ID, which have no value
me> > to me, as the
Nuno Lucas schrieb:
> The problem is that if there are no changes to the working space,
> get_current_revision_id outputs some "bogus" ID, which have no value
> to me, as there are no changes.
>
> Is this a feature or a bug? Shouldn't the current_revision_id be equal
> to the base_revision_id if t
On Tue, Sep 04, 2007, Ralf S. Engelschall wrote:
> 1. copying repository via raw SQLite dump/restore fails
>
>
>This is actually an SQLite problem (and I will forward to the SQLite
>community, too), nevertheless you should be aware he
I decided it was "cool" to include the monotone revision ID on the
build process, so I could know the exact source of a program.
My idea is to have an auto generated .c file with the result of "mtn
automate get_base_revision_id" and "mtn automate
get_currente_revision_id", because that way I would
Markus,
Excellent, many thanks for that very informative reply. Thank you
once again :-).
Tony.
Markus Schiltknecht wrote:
Hello Anthony,
Anthony Edward Cooper wrote:
One question I was asked at work yesterday... What happens if a
database gets corrupted due to an underlying har
Hello Anthony,
Anthony Edward Cooper wrote:
One question I was asked at work yesterday... What happens if a
database gets corrupted due to an underlying hardware failure and the
user, not knowing this, syncs his database? Not such a stupid question
as I have had situations where drivers don
Anthony Edward Cooper <[EMAIL PROTECTED]> writes:
[...]
>Am I correct in assuming that the either one party or both involved
> with the sync exchange checks the data being received/sent. Say by
> rechecking the hashes on all data transferred?
And the signatures of all the certs, yes. The re
Hi again,
One question I was asked at work yesterday... What happens if a
database gets corrupted due to an underlying hardware failure and the
user, not knowing this, syncs his database? Not such a stupid question
as I have had situations where drivers don't report disk errors, you
jus
> "William" == William Uther <[EMAIL PROTECTED]> writes:
William> I actually think something maybe could change here in mtn. When a
William> directory should be dropped in an update, but it contains
unversioned
William> files, rather than failing at that point the versioned files
> "William" == William Uther <[EMAIL PROTECTED]> writes:
William> Other options include:
William> * Move that directory out of the way before you update. Move it
William> back when you return.
William> * Use two working copies
William> * Branch your project - use propagat
Derek Scherger wrote:
> Lapo Luchini wrote:
>> Lapo Luchini wrote:
>>> mtn: fatal: std::logic_error: roster.cc:294: invariant 'fetching
>>> nonexistent entry from nodes' violated
>> This seems not to be solved in trunk (tested as working with
>> 07ae9cb7bea973d20cea3ff3db935744e66e9789).
Did I wri
16 matches
Mail list logo
