On Fri, Oct 24, 2008 at 3:51 AM, Matthew Nicholson <[EMAIL PROTECTED]> wrote:
> Markus Wanner wrote:
>
>> In the archive I've read that boost::program_options didn't do what we
>> want. Looking at the boots documentation, I also see boost::asio - could
>> that perhaps be a better replacement for th
Markus Wanner wrote:
In the archive I've read that boost::program_options didn't do what we
want. Looking at the boots documentation, I also see boost::asio - could
that perhaps be a better replacement for the (unmaintained) netxx?
Anybody used boost::asio before?
I use boost::asio in my ast
Zack Weinberg wrote:
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
* lua: pretty similar to sqlite, except the source inclusion variant is
a bit more complicated. I'm all for dynamic linking and don't see much
of a reason for source inclusion.
I think I mentioned
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> * libz: dynamic linking hasn't posed any problems and the library seems
> to be available on pretty much any system.
libz is a shining example of how to do library stability. (It helps
that it hasn't needed to change in
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> On IRC we recently had a discussion about using boost::date_time instead
> of rolling our own in dates.{cc,hh} - as I've been doing in nvm.dates.
> I've been under the impression, that we do not want to rely on boost
> libr
Lapo Luchini wrote:
(yes I know, it's not easy to check it's the *same* mtn key that's in
your DB as "[EMAIL PROTECTED]" and you received using netsync… and that part
of the UI must be improved to show some unique hash at least when keyids
It would be most useful if the UI would display the ke
Brian May wrote:
Markus Wanner wrote:
Huh? How should that be possible? Isn't it sufficient exchanging known
public keys during netsync?
Only if you trust the database you are syncing from. Especially for
the initial sync from an exmpty database.
Err. I got distracted as I was double checki
Markus Wanner wrote:
Huh? How should that be possible? Isn't it sufficient exchanging known
public keys during netsync?
Only if you trust the database you are syncing from. Especially for the
initial sync from an exmpty database.
Brian May
___
M
Daniel Carrera wrote:
I don't agree. What I propose would be no worse than naming the key
'[EMAIL PROTECTED]' which is the current system. I'm just
making the existing system more convenient.
Getting back on topic (not that the diversion wasn't interesting), you
can't authorize somebody to have
On Thu, Oct 23, 2008 at 5:12 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> Thomas Moschny wrote:
>> So, I don't think we should warn there.
>
> Even make hints about clock skews. Why is that so unwanted for monotone?
Make warns about clock skew (between your local host and its NFS
server) because
Hi,
Thomas Moschny wrote:
> Monotone stores timestamps in the date certs in UTC, of course. Nevertheless,
> clocks for each developer might differ a bit such that commits appear to be
> made in non-chronological order.
That's theoretically possible, though pretty rare in practice.
> So, I don'
Thomas Moschny wrote:
>> Why would you want to warn about that?
>
> So, I don't think we should warn there.
My opinion regarding that warning depends on the offset: of course
something up to a few minutes delta means nothing (simply the user
didn't care use NTP), a delta up to one day means littl
Hi,
Stephen Leake wrote:
> If there is no global shared clock, then developers working in
> different time zones can easily commit revisions to a shared server
> that have timestamps using local times that appear to be "out of
> order" with respect to each other.
Any sane OS today knows the diffe
Stephen Leake wrote:
> TAI might be a better global time choice,
> since it doesn't do leap seconds, and hence is monotonic.
Duh! Isn't UTC monotonic as well, even if it sometimes "changes speed"?
AFAIR leap seconds mean a minute with either 59 or 61 seconds, nothing
never "jumps" ahead or behind
Stephen Leake wrote:
> Markus Wanner <[EMAIL PROTECTED]> writes:
> > I'm just proposing to check the date and warn the user if it obviously
> > doesn't match. It would help making that meta-information more reliable,
> > nothing more, nothing less.
>
> If there is no global shared clock, then devel
Markus Wanner <[EMAIL PROTECTED]> writes:
> I'm just proposing to check the date and warn the user if it obviously
> doesn't match. It would help making that meta-information more reliable,
> nothing more, nothing less.
If there is no global shared clock, then developers working in
different time
Hi,
Ethan Blanton wrote:
> That is correct. It actually caused problems for us at some point,
> when something related to monotone started rejecting those fractional
> second values. The oldest revisions in that Pidgin data started out
> as CVS, were migrated to SVN, and then subsequently migrat
Hi,
On IRC we recently had a discussion about using boost::date_time instead
of rolling our own in dates.{cc,hh} - as I've been doing in nvm.dates.
I've been under the impression, that we do not want to rely on boost
libraries. But in nvm.stripped I'm working on linking monotone against
other libr
18 matches
Mail list logo
