Hi, > 1) hbtrace.c > only some changes to hbtrace are marked TOMERGE and so the marked > patches don't apply. > Can I use the TRUNK version ?
I think you can't. Several features were added to this component, so it doesn't count as pure bugfix. To avoid regressions, no new features should be back-ported to 2.0.x as a rule. > 2) hbmk2.pt_BR.po > there are several commits for this file and for some of them the label > [TOMERGE] was written and then removed... PLEASE don't do it again. If > a file "file.prg" has a "complicated" history due to test with poor > results there are two possibilities: keep the [TOMERGE] label on every > revision on clearly say in the commit "take directly this revision > dropping the history" actually collapsing several commits into one. > Can I use the TRUNK version ? Please you the version committed in: 2009-12-23 02:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) (as for 'don't do it again': you can safely assume that such commits are only done when there is some serious issues along the way, in this case it was codepage problems came at last minute before release. That's life, such thing can happen in development , unfortunately. Anyway, multiple modification should not pose a problem in general.) > 3) 2010-01-05 18:48 UTC+0100 Viktor Szakats > only in hbmk2.pt_BR.po, probably due to not applied patches at point 2. I'm not sure what you mean, but this specific patch of this file shouldn't be merged. The hbmk2.prg -warn fix should go though, it's definitely a manual merge, since multiple changes were done in this one commit. > 4) 2009-12-31 12:43 UTC+0100 Przemyslaw Czerpak > it doesn't apply, but I need to investigate better (probably due to > some missing previous codepage patches) > Should all codepage rfelated patches be MERGED ? This should go as is. hbext*.ch files may need to be applied manually. > 5) 2010-01-13 20:14 UTC+0100 > it doesn't apply because it must be applied to lines added by > "2010-01-13 09:37 UTC+0100 Przemyslaw Czerpak" that was not marked as > TOMERGE that added some similar lines in the same lines confusing the > patch system. Should I MERGE it ? This change is not marked as TOMERGE, so you shouldn't. > 6) 2010-01-18 13:27 UTC+0100 > mapi.c doesn't apply for different formatting.... no problem I can't see the exact problem, but the fix it rightly marked as TOMERGE, maybe it needs to be manually applied. > PLEASE PLEASE PLEASE, in order to not destroy the work I have done up > to now, please DON'T make changes to ChangeLog but instead tell me in > this message what should I do ! > > 29 patches apply cleanly. Thank you. My only comment is that nobody ever told that patches should or would apply cleanly :( There are cases when things has to be done manually. IMO it's almost impossible to design daily "life" around making back-porting patches a no-brainer. [I've went through it in 1.0.1, which I did fully manually BTW.] Based on merging experiences we may try to create some basic committing rules to help the process though, but IMO there is no way to _fully_ avoid automatic merge issues. One such rule could be to commit fixes in distinct commits, if there is any chance that fix needs to be back-ported "AKA [TOMERGE 2.0]-ed". Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
