Re: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> 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

>It is extremely rare for bug fix merges to work automatically with CVS
>commands alone, with or without any renames getting in the way.

First of all, I don't believe that I have implied that merges complete
automatically in the general case.  There will be occasional conflicts
that require manual intervention, but that's the case with any merge
in which there are changes committed on both branches.

But it has been my experience that they work as well as merges performed
while updating in new development.  This is because bug fixes tend to
be small and localized, within established artifacts that aren't modified
during new development.  (In those rare events where there is a conflict,
the new development usually involves additions, rather than changes and
deletions.  I'm not sure if that fact makes life easier or harder, but
it's worth pointing out that observation.)

>If the
>maintenance programmers don't understand explicitly what they're doing
>then they will not succeed.  If you've seen such problems so often then
>you've been working with people who do not understand what they are
>doing, and that's very dangerous for the product they're working on.

There's a distinction between maintenance programmer who make bug fixes
on maintenance branches, vs. new development programmers who merge bug
fixes from the maintenance branches into the next release.  It so happens
that in my world, the two sets of programmers are the same people, but
that's not the general case.  Anyway, the people performing the merge
are expected to know what they're doing with respect to making sure that
the result of the merge meets its specification, i.e. contains both the
bug fix and the new functionality without introducing new bugs.  They're
pretty good at that.

>> and I've seen this more often
>> than I care to remember on vendor branches.

>huh?  what do vendor branches have to do with this?  If you don't
>understand that you have to manually move changes between files that
>have been renamed by the vendor then you should not be messing with such
>complicated things that you do not understand.

Vendor branches are no different from any other branch, as far as
renames are concerned.  Renames performed on the vendor branch must
migrate to other branches when merges are performed.

>> 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?

>Hmmm... I don't use fmt or fold, or cut & paste very often, but that's
>because I use better tools to do what they can do....  I certainly do
>know of their existance though, and what they could do if I needed them.

In other words, even you don't use all of the tools that are at your
disposal. You just the ones you prefer to use.  Sounds familiar.

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