Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 47326: / /trunk/tools/: checkhf-v2.p

From: "Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>
Date: Mon, 28 Jan 2013 16:14:10 -0500
#2 is fine.  The new script seems to run slower though ... but I assume that's because it's doing a much more thorough job?

$ time tools/checkhf.pl epan/dissectors/packet-*.c &> out1.txt

real    0m13.206s
user    0m12.807s
sys     0m0.311s

$ cat out1.txt | wc -l
31821

$ time tools/checkhf-v2.pl epan/dissectors/packet-*.c &> out2.txt

real    1m10.260s
user    1m9.295s
sys     0m0.560s

$ cat out2.txt | wc -l
3014

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Pascal Quantin
Sent: Monday, January 28, 2013 3:32 PM
To: wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 47326: / /trunk/tools/: checkhf-v2.pl

Le 28/01/2013 21:21, Bill Meier a écrit :
> On 1/28/2013 2:58 PM, wmeier@xxxxxxxxxxxxx wrote:
>>
>> Log:
>>   Re-implemention of checkhf.pl:
>>    Main objective: reduce the number of false positives.
>>    Normal usage: the same as for checkhf.pl.
>>
>>   For now: named checkhf-v2.pl
>>
>
> I've just committed a re-implementation of checkhf.pl and named it 
> checkhf-v2.pl.
>
> I'm not really sure how to handle this type of situation:
>
> 1. Retire (delete) checkhf.pl and then commit new version
>    with the same name. (It is a new program).
>    (More or less completely hides the original; It's obviously
>    still in the repository if you know how to find it).
>
> 2. Just commit the new version as a diff from the previous
>    (essentially removing almost all the lines of the old and
>    adding the new). (Keeps the history).
>
> 3. Give the re-implementation a different name.
>    Keep the old in the repository.
>
> Maybe #2 is the way to go....
>
> Thoughts ?
>
> Bill
Hi Bill,

option #2 seems to be the best one for me: this way a svn blame makes it easier to find the previous version and the user can benefit from the new enhanced version without changing his habits.

Regards,
Pascal.

-- 

CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your system and notify the sender by replying to this email.  Thank you.