Follow-up Comment #1, bug #29576 (project monotone):
I understand where you're heading - but the problem is the underlying
architecture of this feature. _MTN/options is supposed to save options which
the user entered on command line to avoid that he has to enter them again -
while it makes no
Thomas Keller invalid.nore...@gnu.org writes:
Follow-up Comment #1, bug #29576 (project monotone):
I understand where you're heading - but the problem is the underlying
architecture of this feature. _MTN/options is supposed to save options which
the user entered on command line to avoid that
Am 17.04.10 13:09, schrieb Stephen Leake:
2) Only save those options back to _MTN/options which have actually been
given by the user on the command line - this would probably need a little
fiddling with the someopt_given flag we set even for options from
_MTN/options (or we leave that alone
On 04/15/2010 02:13 AM, Thomas Keller wrote:
Am 15.04.2010 04:50, schrieb Timothy Brownawell:
Finally, what speaks against integrating usher in monotone's base
completly?
As in make it all a single binary? Not sure what the benefit would be,
Well, I haven't looked at the code and its
Thomas Keller m...@thomaskeller.biz writes:
Am 17.04.10 13:09, schrieb Stephen Leake:
2) Only save those options back to _MTN/options which have actually been
given by the user on the command line - this would probably need a little
fiddling with the someopt_given flag we set even for options
Hi there.
In the latest monotone version (0.47) it displays an error when synchronising
with a file. It happens everytime I do this (it doesn't matter which of my
repositories is involved). This worked fine in the previous 0.45 version.
I don't have problems synchronising to a monotone
Am 18.04.10 00:32, schrieb Darrin Scott:
Hi there.
In the latest monotone version (0.47) it displays an error when synchronising
with a file. It happens everytime I do this (it doesn't matter which of my
repositories is involved). This worked fine in the previous 0.45 version.
Thanks
On Sat, Apr 17, 2010 at 6:34 AM, Thomas Keller m...@thomaskeller.biz wrote:
This is only partially a problem of the hook. The options system simply
has no general code to accept --no-something options which would
switch the default of the --something value to the opposite.
Allowing a
On Sat, Apr 17, 2010 at 1:27 AM, Thomas Keller invalid.nore...@gnu.orgwrote:
1) Save any given options back to _MTN/options at the very end of the
execution (f.e. in monotone.cc) _after_ it has been clear that no exception
occurred - so we don't remember possibly harmful settings.
2) Only
Am 18.04.10 00:48, schrieb Derek Scherger:
On Sat, Apr 17, 2010 at 6:34 AM, Thomas Keller m...@thomaskeller.biz wrote:
This is only partially a problem of the hook. The options system simply
has no general code to accept --no-something options which would
switch the default of the
Am 18.04.10 00:53, schrieb Derek Scherger:
On Sat, Apr 17, 2010 at 1:27 AM, Thomas Keller invalid.nore...@gnu.orgwrote:
2) Only save those options back to _MTN/options which have actually been
given by the user on the command line - this would probably need a little
fiddling with the
Am 18.04.10 00:57, schrieb Thomas Keller:
Am 18.04.10 00:48, schrieb Derek Scherger:
On Sat, Apr 17, 2010 at 6:34 AM, Thomas Keller m...@thomaskeller.biz wrote:
This is only partially a problem of the hook. The options system simply
has no general code to accept --no-something options which
On 04/15/2010 07:59 AM, Thomas Keller wrote:
Am 15.04.2010 13:33, schrieb Thomas Keller:
I played around with [mtn://-style uris] further, there are a couple of serious
bugs in
this feature. Apparently the uri scheme only works if a port (and may it
only be the standard port 4691) is given and
Hello all,
I've noticed mtn uses a lot of memory while committing changes to a ~11MiB
binary file. I ran the commit with:
valgrind --tool=massif mtn commit -meh
I've attached the massif log file.
Here's the salient bit at peak heap usage:
| | -97.83% (1,187,110,745B) 0x60A1EBF:
14 matches
Mail list logo
