[p4] checking success / failure of sync

[Smith, Jeff]

I think you are combining two separate UI concepts of failure.
Following your strict definition, no tool ever fails that doesn't crash.
If that's true, a tool should never set an error code because if it
follows its codepath to a succesfull exit it "completed normally."

But from a UI perspective the tool fails anytime it doesn't do what the
user wanted to have happen and that is what error codes are all about.

When the user wrote the client spec and performed the sync, it was very
unlikely that he intentially placed a writeable file somewhere in the
client area knowing that the Perforce would be unable to replace it.  In
other words, good UI defines failure from user expectation and not from
the tool code path.  After all, the tools exists to service us and not
the other way around :-)

Furthermore, when a tool is written the writer had better have a pretty
good idea what constitutes "normal end-to-end behviour" for a run.  In
the case of a Perforce sync, that's all the files defined in the config
spec being written.  For a compiler, it's a normal compile.  When that
doesn't happen, it only makes sense to set a return code other than 0 to
let the user know that his expectations weren't met.

Jeff

-----Original Message-----
From: Matthew Janulewicz [mailto:mjanulew at alarismed.com] 
Sent: Tuesday, December 14, 2004 6:40 PM
To: Grills, Jeff; NIGGEMYER Brant; perforce-user at perforce.com
Subject: Re: [p4] checking success / failure of sync


I still think that that, specifically, is a failure of the client spec,

since there is a setting (noclobber) to toggle that on and off.

Having a writeable file in your spec that 'needs clobbering' points to  
editing without 'opening for edit' in Perforce, which is against the
grain  
of how the tool is supposed to be used.

I can see your point, and it is just nitpicking (I like to nitpick), but
I  
still think that in a technical sense, the failure in this case is still

not a 'sync action' failure, because the sync action is following rules

(noclobber) that are set up specifically for it to follow. The results
may  
not be what you intend, but by all accounts, the results are exactly
what  
you are asking for with your client spec.


-Matt


On Tue, 14 Dec 2004 15:31:39 -0800, Grills, Jeff <jgrills at soe.sony.com>

wrote:

>
> A writable file won't be replaced by perforce, and IMO causes a sync 
> operation to fail. That's pretty common around here.
>
> But, back to the original question. You might be able to discard 
> stdout and look for any lines being sent to stderr as an indicator 
> that the sync failed.
>
> j
>
> -----Original Message-----
> From: perforce-user-admin at perforce.com 
> [mailto:perforce-user-admin at perforce.com] On Behalf Of Matthew 
> Janulewicz
> Sent: Tuesday, December 14, 2004 4:51 PM
> To: NIGGEMYER Brant; perforce-user at perforce.com
> Subject: Re: [p4] checking success / failure of sync
>
> Partly opinion, partly philosophy, partly zen:
>
> I work on the assumption that a sync NEVER fails, and maybe that's why

> there is no errorlevel set on this command. Client views not being 
> properly handled are a problem with the views, not the sync action 
> itself. Short of the server crashing mid-sync (which is still not the 
> sync action's fault) a sync can only 'fail' because something else is 
> set up
>
> incorrectly. A sync will always do exactly what you ask it to do (by 
> way
>
> of your client spec), success or failure depending on the quality of 
> your client spec.
>
> I feel the same way about compilers, for what it's worth. I don't 
> believe that a compile ever 'fails' as such. An error is an error in 
> your code,
>
> not the compiler. So checking for a failed compile is to check the 
> quality of your code. Garbage in, garbage out. A failed compile, to 
> me, points to
> a level of *success* for the compiler itself. Failure = success. Chew
on
>
> that for a bit.
>
> In that vein, this might be a sticky problem. You will have to parse 
> output, but approaching it from this other angle, it would behoove you

> to pre-verify that the client specs you are using are legit. You would

> have
>
> to parse/account for all kinds of errors, probably starting with all 
> the
>
> permutations of '... not in client view ...', etc. I don't think there

> is an easy way to do it.
>
> -Matt


_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user