On Thu, Apr 09, 2009 at 06:04:22PM -0700, Mike Kupfer wrote:
> Agreed, though if you know the area you're working in, you can do a
> "make clobber" for part of the tree and then do "hg stat
> ".
True. Still could be a massive amount of deletion.
> I'm also thinking about changing nightly(1) so
> "Danek" == Danek Duvall writes:
Danek> Having to do a make clobber just to have a clean "hg stat" seems
Danek> a bit sketchy to me;
Agreed, though if you know the area you're working in, you can do a
"make clobber" for part of the tree and then do "hg stat
".
I'm also thinking about chan
Alan Burlison wrote:
> Darren J Moffat wrote:
>
>> Is it possible we could have comchk work similar to webrev does now -
>> in fact using the same its config files recently introduced. So that
>> when it is run inside SWAN it uses sac.sfbay instead of
>> arc.opensolaris.org ?
>
> I don't thin
On Thu, Apr 09, 2009 at 04:07:21PM -0700, Mike Kupfer wrote:
> > "Mark" == Mark J Nelson writes:
>
> Mark> Yes and no. It would be great to get a detailed, appropriate
> Mark> .hgignore file for ON. But as it currently stands, such a file
> Mark> overwhelms the Mercurial implementation of
Darren J Moffat wrote:
> Is it possible we could have comchk work similar to webrev does now - in
> fact using the same its config files recently introduced. So that when
> it is run inside SWAN it uses sac.sfbay instead of arc.opensolaris.org ?
I don't think that would help as the data comes
> "Mark" == Mark J Nelson writes:
Mark> Yes and no. It would be great to get a detailed, appropriate
Mark> .hgignore file for ON. But as it currently stands, such a file
Mark> overwhelms the Mercurial implementation of hgignore. Fixing
Mark> either the ON build (to make the file more sane)
James Carlson wrote:
> Richard Lowe writes:
>> Richard Lowe writes:
>>
>>> It does -appear- that the CSV is now eliding closed cases. This was
>>> never previously the case, and when we discussed this interface with (at
>>> the time) John Plocher, were told this was by intent, and it was
>>> reas
Mark J. Nelson wrote:
> Jordan Brown wrote:
>> I was just surprised when an "hg stat" didn't tell me about the files
>> I'd created but hadn't "hg add"ed, so I looked around and found that
>> .hgignore is set to ignore everything.
>>
>> Is that the long-term plan?
>
> Yes and no. It would be grea
Richard Lowe wrote:
> Alan, did you change anything here?
Nope.
> I will note, however, that all information contained in the CSV *does*
> display on the (new) open caselog, so it seems doubtful it would be
> hiding things for that reason?
The mechanism used to produce the new caselog at
http:
I cc'd the SCM migration folks, in case they want to either correct or
corroborate my assertions below.
Jordan Brown wrote:
> [ Resend to correct alias ]
>
> I was just surprised when an "hg stat" didn't tell me about the files
> I'd created but hadn't "hg add"ed, so I looked around and found th
Richard Lowe writes:
> Richard Lowe writes:
>
> > It does -appear- that the CSV is now eliding closed cases. This was
> > never previously the case, and when we discussed this interface with (at
> > the time) John Plocher, were told this was by intent, and it was
> > reasonable to rely on.
>
>
Richard Lowe writes:
> It does -appear- that the CSV is now eliding closed cases. This was
> never previously the case, and when we discussed this interface with (at
> the time) John Plocher, were told this was by intent, and it was
> reasonable to rely on.
Actually, scratch that. The pieces m
Chris Gerhard writes:
[redirecting somewhat]
> While preparing an RTI I ran hg pbchk which in turn calls hg comchk
> and it always reports an ARC case as missing.
>
> : eacces.eu FSS 219 $; hg comchk
> remote: Not trusting file /share/bld/ONclones/onnv-clone-eu/.hg/hgrc
> from untrusted user bld
13 matches
Mail list logo
