>--- Forwarded mail from [EMAIL PROTECTED] >[ 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
