On Sat, 19 Sep 2009, Szak�ts Viktor wrote: Hi,
>> 1. generate locally .diff file from last library upgrade using >> svn diff -r <revision> ... >> if possible check <revision> number in log file. > This will give a diff between lib versions, but local > modifications won't appear separately unless they are > always repatched in separate commit after each upgrade. Exactly and they should be done in such way, I asked about it few times in the past: 1-st commit of 3-rd party code should always contain unmodified version then we should commit our patches. If it's a problem now then it can be resolved immediately by committing unmodified code then storing SVN revision number in log file and committing our patches. > But once this is missed by mistake, the chain becomes > broken and it becomes quite an effort to repatch it right. In such case you will have to take real source code. Just like now to update .diff files so I do not understand why I have to make sth many times on each update when I can make the same only once just before upgrading to new version. >> 2. commit new library source code >> 3. patch new library using .diff file generated in step 1 and >> update log file adding information about current revision >> number >> 4. commit modifications >> The log file is optional but it can reduce time necessary to validate >> exact >> revision number from last library update. > Hm, current method with .dif isn't prefect either, but > IMO it more clearly documents the fact that we're dealing > with locally patched code, and it makes it easier to > separate patching and lib upgrading steps. Your method > puts all the burden to lib upgrader, which is IMO more > error prone. > We should also consider that patching sources locally > happens quite rarely and it should only be done if > absolutely necessary. Upgrading however, may happen > quite frequently (speaking of sqlite3, libpng). > .dif method also makes it easy to flush those patches > upstream (by any contributor) which would be the ultimate > goal after all, rather than rolling them locally forever. I'm sorry but I do not agree. For me it's only unnecessary job which can be eliminated by committing clean version of new library in 1-st step what for me is the perfect solution. I do not understand why I have to watch for modifications create diffs with local copy of original source, update them, etc. in each commit (I do not believe it will happen without errors) and on each update I have to repeat things I can made without any diff file using SVN. I do not see anything what we can benefit having such .diffs files in SVN. For sure they do not help in any updates because to create them it's necessary to compare with original library so it will be always safer to create .diff file just before an update to be sure that no one forgot to update the one in SVN. IMHO it's only unnecessary additional job for developers which can be source of potential problems if someone use such not updated or wrongly updated (i.e. developer was too lazy and created .diff entry "by hand" with mistake) .diff instead of generating new one so it will not help in future upgrades. In summary you are asking developers to use SVN to replicate SVN job manually. Creating .diff files is one of the most important thing in different versions systems. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
