A quickly answer: On Sat, Jan 23, 2010 at 1:45 AM, Viktor Szakáts <[email protected]> wrote: > 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.
Ok > >> 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.) It's ok, I just wanted to say that for clean patch apply all the commits should be applied.... > >> 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. I will check later. > >> 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. But 2010-01-13 20:14 UTC+0100 adds a line in function hb_hashGetCItemPtr() added in "2010-01-13 09:37".... or we add both or none... > >> 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.] I'm doing it quite manually to extract commits and hunks. But you are a "core" developer, I'm just helping and I can't know if a patch is really a bug fix or something else... For example in one of your patches (about unicode overflow protection) there were changes to win_prn3 (TEXT(0)) not listed in the Changelog and I can't know if they are needed or not... in anay case, they don't apply.. > > 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. Yes, for example if you set a [TOMERGE 2.0] label for previous commits, the comit message should be Added [TOMERGE 2.0] to rev XY and not "updated previous Changelog...." Francesco _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
