>> 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.
>
> The hbmk2.prg -warn fix should go though, it's definitely
> a manual merge, since multiple changes were done in
> this one commit.
Ok, it was my fault, the patch should be:
@@ -1577,16 +1587,19 @@
CASE cParamL == "-warn" .OR. ;
- Left( cParamL, 7 ) == "-warn="
+ Left( cParamL, 6 ) == "-warn="
DO CASE
- CASE SubStr( cParamL, 8 ) == "def" ; hbmk[ _HBMK_nWARN ]
:= _WARN_DEF
- CASE SubStr( cParamL, 8 ) == "no" ; hbmk[ _HBMK_nWARN ] := _WARN_NO
+ CASE SubStr( cParamL, 7 ) == "def" ; hbmk[ _HBMK_nWARN ]
:= _WARN_DEF
+ CASE SubStr( cParamL, 7 ) == "no" ; hbmk[ _HBMK_nWARN ] := _WARN_NO
OTHERWISE ; hbmk[ _HBMK_nWARN ]
:= _WARN_YES
ENDCASE
>
>> 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
>
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
