http://code.google.com/hosting/createProject
On Tue, Dec 30, 2008 at 12:31 PM, Uriel wrote:
> On Tue, Dec 30, 2008 at 4:06 PM, C H Forsyth wrote:
>>>Knowing *who* made the change is often even more useful than the change
>>>comment.
>>
>> yes. i use ls -lm on our trees, but that might not work
On Tue, Dec 30, 2008 at 4:06 PM, C H Forsyth wrote:
>>Knowing *who* made the change is often even more useful than the change
>>comment.
>
> yes. i use ls -lm on our trees, but that might not work on less direct things
> like sources.
It would work if the development trees were public...
uriel
> If one buys this argument, then namespaces are not valid security constructs
they are not security constructs at all. though ftpd and a few friends
use rfork(2) to create a pgrp that doesn't allow attaches. very simple
and effictive, but probablly not strong security.
> either, and Plan 9 sec
On Tue, Dec 30, 2008 at 2:22 AM, Nathaniel W Filardo wrote:
>
> If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then
> the system is one step closer to supporting the above. There is some
> machinery for sealing off #p that I do not recall in full detail but may
> well be
>Knowing *who* made the change is often even more useful than the change
>comment.
yes. i use ls -lm on our trees, but that might not work on less direct things
like sources.
Knowing *who* made the change is often even more useful than the change comment.
uriel
On Tue, Dec 30, 2008 at 2:48 AM, Charles Forsyth wrote:
>>> i've rarely found per-change histories to be any more useful than
>>> most other comments, i'm afraid.
>
>>And that meant that math texts and math te
On Sat, Dec 27, 2008 at 12:21:49PM -0800, Roman Shaposhnik wrote:
> True. But why that should be a problem in practice? If the process
> belongs to a user X that means user X has control over it. Thus the
> behavior of accidental consumption of an fd that was meant to be consumed
> by some other pr
