Christof Petig schrieb:
PS: I _shall_ not need funding for the summit. IMHO if fully apprenticed
university engineers with a paid job ask for funding something is going
wrong indead. OTOH paying the flight just because of a hobby hurts my
family's holiday budget, too.
Please do not get me
Christof Petig schrieb:
Please do not get me wrong: I was explaining why I could not honestly
ask for funding, I was not intending to say that engineers should not
need funding.
It's difficult to get sensitive stuff non ambiguously: please insert in
general after engineers.
Christof
Hi,
I separated the less controversial automate extensions of cvssync3 into
the branch net.venge.monotone.cvssync.candidates .
Can you take a look whether these are fitting into mainline?
(Documentation is added, a ChangeLog isn't yet)
Namely they are:
db_get domain varname
db_set domain
Hi,
here's the second part of my automate proposals:
How do you feel about adding an automate command to query the current
workspace (e.g. branch, root dir, default key, database location etc.).
These values are located inside .../_MTN/options and I don't want to
write yet another routine to
Christof Petig schrieb:
db_get domain varname
db_set domain varname value (like mtn db get/set)
cert name value (like mtn cert)
Very cool and useful also for me =)
put_file [base-id] contents
put_revision changeset
What is put_revision's format? Is this something which could be
Christof Petig schrieb:
What about
$ mtn automate get_workspace
database /usr/local/lib/monotone.db
branch net.venge.monotone.cvssync.refactor
keydir /home/christof/.monotone/keys
key [EMAIL PROTECTED]
workspace /home/christof/projects/monotone
mtn automate get_option
Thomas Keller schrieb:
Christof Petig schrieb:
What about
$ mtn automate get_workspace
database /usr/local/lib/monotone.db
branch net.venge.monotone.cvssync.refactor
keydir /home/christof/.monotone/keys
key [EMAIL PROTECTED]
workspace /home/christof/projects/monotone
mtn
Christof Petig schrieb:
On the other hand, get_option could be nicely symmetric to a not yet
existing set_option to override workspace defaults. Opinions?
... It would have been a good idea to browse the source instead of the
documentation :-(
This is now documented.
Thomas.
--
ICQ:
I have a mostly completed set_option that might meet this need. I
hadn't placed it in the automate group of functions, but rather the
general workspace set. Would it be better placed in automate?
-Ben
On 12/19/06, Thomas Keller [EMAIL PROTECTED] wrote:
Christof Petig schrieb:
What about
$
Thomas Keller schrieb:
put_file [base-id] contents
put_revision changeset
What is put_revision's format? Is this something which could be
tweaked/used to let monotone understand its own diff format (the header
of that is a changeset, I believe)?
I wanted to implement it least invasive
Ben Walton schrieb:
I have a mostly completed set_option that might meet this need. I
hadn't placed it in the automate group of functions, but rather the
general workspace set. Would it be better placed in automate?
I guess so. Since many frontends exclusively use automate stdio a
different
On 12/18/06, Zack Weinberg [EMAIL PROTECTED] wrote:
On nvm.experiment.pcre is a version of monotone that uses Philip
Hazel's PCRE (Perl Compatible Regular Expressions) library instead of
boost::regex.
I forgot to mention what I think is the #1 reason we should do this,
and the biggest
Zack Weinberg schrieb:
actually do us some good (in particular, it will let us properly
resolve the Debian crasher bug that was reported just before 0.31).
Uh, boost is built without ICU here - maybe _that_ is the proper fix?
patrick mauritz
___
Zack Weinberg wrote:
we know distributors want us to move toward using
unbundled libraries, and PCRE is nice and stable, so this should not
pose us any problems.
with FreeBSD devel/monotone port maintainer hat
Hey dude, what about that external LUA could be usable after all
because we can
Hallo,
On 12/19/06, Patrick Mauritz [EMAIL PROTECTED] wrote:
Zack Weinberg schrieb:
actually do us some good (in particular, it will let us properly
resolve the Debian crasher bug that was reported just before 0.31).
Uh, boost is built without ICU here - maybe _that_ is the proper fix?
Ben Walton wrote:
The downside is reliance on an external tool, which would most likely
have negative effects on the non-unix users. I'm confident that patch
is available for all unix platforms, but the windows folks would need
cygwin then, I believeI guess this is a large downside.
It's
On Mon, Dec 18, 2006 at 10:40:47PM -0800, Zack Weinberg wrote:
PCRE if available; we know distributors want us to move toward using
unbundled libraries, and PCRE is nice and stable, so this should not
pose us any problems.
Along those lines, are there any remaining Monotone-specific patches
Alex Queiroz wrote:
Hallo,
On 12/19/06, Patrick Mauritz [EMAIL PROTECTED] wrote:
Zack Weinberg schrieb:
actually do us some good (in particular, it will let us properly
resolve the Debian crasher bug that was reported just before 0.31).
Uh, boost is built without ICU here - maybe _that_ is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lapo Luchini wrote:
It's like it does use heavily UNIXy things like fork, I guess...
Rephrase as: IT'S NOT like 'diff' does rely heavily on things like fork()...
- --
Lapo Luchini
[EMAIL PROTECTED] (OpenPGP X.509)
www.lapo.it (Jabber, ICQ, MSN)
On 12/19/06, Lapo Luchini [EMAIL PROTECTED] wrote:
Hey dude, what about that external LUA could be usable after all
because we can overwrite system.os() with a null value anyway stuff?
That's nice and all, but is not what I want to do right now. One
thing at a time.
zw
20 matches
Mail list logo
