RE: CVS Update Behaviour

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto: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 
> 
> It is extremely rare for bug fix merges to work automatically with CVS
> commands alone, with or without any renames getting in the 
> way.

It is?  It is possible that we have different sorts of bugs than those
you're familiar with, but we find that bug fixes often merge very
nicely without manual handling.  This is important; our business mandates
that we maintain different branches for different customers.  (We have
few and large customers, compared to many other software houses.)

Obviously, this will not work when files have been renamed, but in
that case the changes between versions are likely to be so large that
it really doesn't matter.  In many cases, the bug has been removed
in the redesign anyway.

> 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.
> 
It seems to me that the question is not understanding, but whether it
is desirable.  It would be nice if CVS would track vendor renames, but
it would have to be able to figure out vendor renames, and in any case
the sources we track tend to be kept in CVS anyway, so the supplier is
unlikely to rename things gratuitously.