I agree.
On 3/25/08, Amos Jeffries [EMAIL PROTECTED] wrote:
I think its probably time we added aufs as one of the available default
filesystems.
Comments?
Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.
--
On Wed, 2008-03-26 at 10:14 +1300, Amos Jeffries wrote:
Henrik Nordstrom wrote:
Revision 8905:
src/comm.cc: In function 'int comm_connect_addr(int, const IPAddress)':
src/comm.cc:1144: warning: passing NULL to non-pointer argument 2 of
'void* memset(void*, int, size_t)'
make[1]: ***
On Tue, 2008-03-25 at 17:18 -0600, Alex Rousskov wrote:
I already deleted generated files from the eCAP branch because I thought
somebody said we should all do it (and I hate how they spoil diffs) :-).
It's been discussed, and I have proposed doing it next week unless
someone objects.
I'll
On Wed, 2008-03-26 at 10:15 +1100, Robert Collins wrote:
The conflict resolver for revert uses a big hammer to make the tree
identical; in the case of local edits the merge above will conflict
and
keep your edit, the revert above will discard it.
'revert' is 'become'
'merge' is 'apply
On Wed, 2008-03-26 at 11:09 +1300, Amos Jeffries wrote:
I think its probably time we added aufs as one of the available default
filesystems.
On Linux yes, not sure about in general due to the depencendy on kernel
POSIX threads...
It's a pity POSIX AIO doesn't include open/close. If it did we
On Tue, 2008-03-25 at 09:09 -0600, Alex Rousskov wrote:
That's a good idea! The level can also change depending on the caller
(e.g., use eCAP level if eCAP code is calling the shared code).
Yes, ideally there would be a transaction state tied to the debug,
allowing expressions like comm I/O on
On Thu, 2008-03-27 at 00:02 +0100, Henrik Nordstrom wrote:
I was more thinking of the resulting changeset and what you meant by
your statement above
you are committing a changeset that happens to alter previously done
work, but bzr does not consider this a cherrypick or merge - the
