That would IMO be much more difficult to do than applying the selected patches only, since the selected ones are usually well separated, while the patches in general are no so much so. Take the hbwin patches for an example, or any patches which were done after type changes.
Plus such is doubtful, because you say all your patches should go (after marking some of the for merge), while I say only my marked ones should go, and while this system already looks unsystematic (f.e. what about the other developers?), it's the perfect way to confuse anyone who's trying to do the job. This could be avoided by simply copying current trunk to 2.0.x and say we were developing 2.0.1 all along. I don't agree with that though, because that wasn't how f.e. I started to make changes, which means there may be things which are not necessarily stable, were not necessarily tested on all targets, and may break compatibility promises. Even some of your changes may break it, f.e. adding WIN32PRN to xhb. (it's a good change, but nevertheless not a 2.0.1 one), or 'renamed DB_DBFLOCK_XHB64 => DB_DBFLOCK_HB64', or WinCE function cleanup. So to make merging task easier, maybe it'd be useful if you marked the remaining ones you think should go, as TOMERGE. A quick review revealed that there are some which may indeed qualify as bugfix but not marked as such. Of course we can let it to Francesco's best judgment. Brgds, Viktor On 2010 Jan 25, at 11:21, Przemysław Czerpak wrote: > On Mon, 25 Jan 2010, Alex Strickland wrote: >> dru...@users.sourceforge.net wrote: >>> 2010-01-23 01:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) >>> * harbour/src/vm/memvars.c >>> ! fixed RELEASE ALL [LIKE | EXCEPT<skeleton>] command - thanks to >>> Enrico for information >> [ TOMERGE 2.0 ] ? > > Everything what I've committed should be merged in 2.0 because > it's very hard to take such modifications separately. > Probably only core developers who well knows Harbour internals > can apply patches separately but even in such case it's very > big risk of making some mistakes. > > best regards, > Przemek > _______________________________________________ > 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
