Re: icu digest, Vol 1 #685 - 2 msgs

FYI convrtrs.txt is not installed with gmake install any more.  Of the 
non-binary files installed, only the man pages, license.html and headers 
are installed.

George Rhoten
IBM Globalization Center of Competency/ICU  San José, CA, USA
ICU main website: http://oss.software.ibm.com/icu/index.html




Alan S Liu/San Jose/IBM@IBMUS
Sent by: [email protected]
03/26/2004 12:53 PM
 
        To:     Steven R Loomis/Cupertino/IBM@IBMUS
        cc:     [email protected], [email protected], 
Markus Scherer/Cupertino/IBM@IBMUS
        Subject:        Re: icu digest, Vol 1 #685 - 2 msgs


I think I'm going to post this back out to the list to see if any other
opinions arise.  I'm also going to CC Markus directly to see what he
thinks.

[Alan S Liu/San Jose/IBM@IBMUS; [email protected];; IBM Globalization;
5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155]



Steven R Loomis/Cupertino/IBM
03/26/2004 11:54 AM

To
Alan S Liu/San Jose/IBM@IBMUS
cc
[email protected]
Subject
Re: icu digest, Vol 1 #685 - 2 msgs





Hello,
Thanks for your input. In fact on a recent  diff excursion  (diffing all
packaged source versions of ICU against their respective CVS tags..) I
ended up using the facility of diff which can ignore a regular expression.
( -I i believe) .

You also have a good point about the user files.. such as convrts.txt
which is installed on the user's side.

Alan do you know if other diff tools (compareIt?) can ignore these tags?
webcvs could be modified as well ..

-s




Alan S Liu/San Jose/IBM
03/26/2004 11:30 AM

To
[email protected]
cc
Steven R Loomis/Cupertino/IBM@IBMUS
Subject
Re: icu digest, Vol 1 #685 - 2 msgs





Frank:

Thanks for your reply.  I'm bringing Steven Loomis into the discussion,
who is the most familiar with the issues we've run into with the tags.  In
fact, Steven is the person best suited to reply.  We can always copy this
back out to the list, esp. if any one else shows any interest in what is
admittedly a relatively low level issue.

I'm the person implementing this, but I'm not really the person driving
it, since I don't do any CVS repository maintenance -- Steven does that
stuff.

P.S. The light of true reason is always welcome :-).

Alan

[Alan S Liu/San Jose/IBM@IBMUS; [email protected];; IBM Globalization;
5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155]



Frank Griswold <[email protected]>
03/26/2004 10:05 AM
Please respond to
griswolf


To
Alan S Liu/San Jose/IBM@IBMUS
cc
[email protected]
Subject
Re: icu digest, Vol 1 #685 - 2 msgs






Alan:

I took this off line because it seems silly to waste many peoples time
with it. Feel free to reply to the reflector if you prefer.

I don't know if CVS keywords are pervasive in ICU code. If they are not,
then most of what I have to say is moot. Certainly, since I work with ICU
mostly as a user (though I have found it needful to fix the occasionaly
ICU bug that impacts my use), I have less personal stake in the outcome
than a developer would have. However, in the interest of helping you see
the light of true reason <grin>, here's my take:

The CVS keywords are there because some people find them useful. At Rogue
Wave, we use Perforce which has a similar utility; and have long used $Id:
because it gives us quite a bit of utility for very low effort:

1: Each file is perfectly self-identified. In a multi-branch environment
with ongoing support for several releases, this can be a critical
piece of disambiguation.

2: Diffs are self-identified. The top few lines of a diff extend point 1
for each file, as well as telling you the direction of the diff. As a
long time code maintainer, I assure you it is possible to lose track
mentally of which way you ran the diff; particularly if it was
generated by some kind of tool. $Id: lines give that information back
immediately.

3: Support effort is less often misplaced. This is just point 1 again,
from the perspective of someone trying to help the typical hapless
(l)user. Believe me when I tell you that users lie about versions
(usually from ignorance). $Id: lines may lie as well, if someone has
made changes on site; but they are -much- more accurate than users.

Summary: The added value of unambiguous file version identification is
much greater than the added cost of extra diff lines.

If you truely find the extra diff lines difficult to deal with, I bet
there is already an RCSdiff utility that can be tuned to do what you
want. Have you looked? I did a very quick google on "rcsdiff" and found
at least one hit that looked promising:

http://www.rtr.com/winpak/Documentation/rcsdiff.htm

In any case, I'm quite sure that it is the matter of only an hour or
two(*) to create a script to do it. The basic idea would be to filter the
keyword lines out of the files of interest prior to running diff. The
alternative of filtering diff output is harder because diff adds various
kinds of context depending on how it is invoked. But for myself, if the
diff is intended for human consumption, I much prefer to leave them in.

(*)I would have said "a few minutes" if I were doing it for myself,
one-shot. The added hours are for error handling, robustness, better
output clarity. Add a few more hours if you need a compiled version.

>> To: [email protected]
>> Subject: Proposal: Remove CVS keywords from source
>> From: Alan S Liu <[email protected]>
>> Date: Thu, 25 Mar 2004 19:31:35 -0800
>>
>> http://www.jtcsv.com/cgibin/icu-bugs?findid=3666
>>
>> Affects: All ICU projects.
>>
>> Proposal: Remove *all CVS keywords* from all ICU source code.
>>
>> Rationale: These keywords are not really useful and they cause spurious

>> differences.  Steven Loomis knows more about this and can supply
further
>> details.
>>
>> For a list of affected keywords see:
>> http://www.loria.fr/~molli/cvs/doc/cvs_12.html

-- frank griswold




_______________________________________________
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu