info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS Update Behaviour


From: Paul Sander
Subject: Re: CVS Update Behaviour
Date: Mon, 25 Feb 2002 00:17:58 -0800

>--- Forwarded mail from address@hidden

>[ On Friday, February 22, 2002 at 20:57:01 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> >--- Forwarded mail from address@hidden
>> 
>> >[ On Friday, February 22, 2002 at 13:25:37 (-0800), Paul Sander wrote: ]
>> >> Subject: Re: CVS Update Behaviour
>> >>
>> >> And every time a merge is done from a branch where a rename was done on
>> >> one of the branches.
>> 
>> >And what has been said about that for years now?  DON'T DO THAT!!!!
>> 
>> Yeah, right after it was said that such a capability is a requirement...
>> Such merging is common in the maintenance phase of a product.

>Huh?  What kind of idiocity is that?  Since when are renames an absolute
>requirement of maintenance?  Anyone silly enough to do a rename during
>maintenance and to do so only on the patch branch, is going to get what
>they deserve!  (I.e. a whole lot of unnecessary confusion and a lot of
>extra manual work during merges! :-)

Renames are not usually a requirement of maintenance, but they are a
requirement of new development.  Bug fixes are done during maintenance,
and merged into new development.  That means that bug fixes are merged
into new development, often after prior new development involved renames.
This mode of operation is common!  Sometimes renames are done on a task
branch and folded into the next release, and I've seen this more often
than I care to remember on vendor branches.

>>  It's not a standard
>> tool, so it falls well outside their experience.  (Most are not even
>> familiar with all of the standard Unix tools.)

>"patch" has been a "standard" tool in unix development for nearly two
>decades now.  Prior to that the commonly used tool that can do the exact
>same job with only slightly less success and using the exact same tool
>to create the diff, was called 'ed'.  It's been around for over three
>decades now.  Time to crawl out from under your rock and get with the
>program Paul!

Just because a tool is "standard" does not mean it's well-known or
well-supported.  40% of the Unix platforms I use regularly (Solaris and
NetBSD) don't even supply the tool, and I admit that this is a much lower
number than I expected.  (AIX, HP-UX, and MacOS X do supply it.)

When's the last time anyone's used tsort(1), join(1) or fmt(1), or even
cut(1), paste(1) or fold(1), and Greg's favorite ed(1), even on this list
that's full of toolsmiths?  ls, diff, ln, cc, ld, vi, more, make, dbx, nm,
ar, tar, cp, chmod, ftp, cd, pwd, compress, sort, gzip (despite its non-
standard status), telnet, xterm, id, mailx, echo, test, date, and perhaps
a dozen or so other standard tools plus another dozen or so shop-specific
tools make up the world as far as my developers are concerned.  Virtually
everything else to them is as obscure and unknown to them as the tools I
listed in the first sentence of this paragraph.  Because the developers
are doing the merging and they don't know about "patch", chances are they
won't choose to use it.

>--- End of forwarded message from address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]