On Mon, 11 Sep 2000, Mark Brown wrote: > > This only works, if the diff's are independend or one diff is diff are on > > the top of each other. So I do not see the advantage of many diffs. > > The advantage of having multiple diffs is that distinct changes can be > kept distinct. You do need a system for ensuring that the diffs are > applied in the correct order and so on, but given that multiple diffs > are very much nicer. It becomes very much more obvious what has been > changed and how, not to mention far simpler to adjust the set of changes > that have been applied. As an added bonus, the handling of upstream > source that include patches is more elegant.
Is it realy so much easier? I do not have experiences with maintaining patched software. But I experienced for example, that I had to made major changes to apply a patch for a 2.0.30 kernel to a debianiced 2.0.36 kernel. And with I the software I develop, there is seldom one patch that would not collide with an other. I imagine it much easier to have the orginal code and the debian code, where I can get from one to the other through one diff. Correct me, if I err, but when you have an code with two patches and want to change patch 1 to an newer version of this, wouldn't you need to change patch 2 then, too? > Aside from requiring CVS this looses information for anyone without > access to the repository. That's a hassle when you get maintainer > changes and makes the packaghe source itself much less useful than it > could be. I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
