X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com Message-ID: <50EC7AFD.7050006@iki.fi> Date: Tue, 08 Jan 2013 22:01:01 +0200 From: Andris Pavenis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: DJGPP ports of GNU packages and version control Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com I guess it would be nice to have a possibility of version control for DJGPP ports of various GNU Packages. It is easy to forget to apply patches for a new version (for example last update of DJGPP port of binutils-2.23.1 (we all make mistakes sometimes) We often have own patches on top of upstream package and it is easier to handle using some version control system In last months I have bit experimenting with way how to manage DJGPP port of GCC with minimal required additional efforts. I guess the same approach could be applied for other packages. Seems that GIT is rather well suited for that purpose. After beginning to use GIT (I began when I was as a consultant at Sony Mobile Communications in Sweden for some month) I do not want to return to CVS or Subversion any more. So currently I have my own GIT server on a separate machine (unfortunately not visible from outside network). There are 2 branches for upcoming GCC version (and the same for old 4.7.X): the first for changes required to build DJGPP targeted cross-compiler, the second one - additional changes required for native compiler. I earlier maintained a patch-set initially as gccXXXs2.zip and later djcross-gcc-XXX.tar.bz2. It is however much easier to generate these patch-sets from GIT repository using not so complicated script. Current version builds all source packages and source RPM after that when run, so only rpmbuild --rebuild ... remains with following fixing problems if found. It would of course be better to have that repository publicaly visible. With this approach update to new version would look like: 1) pull updates from upstream to required branch on developer system 2) merge changes into DJGPP related branch or branches and resolve problems (merge conflicts, build errors, etc) 3) push branches including ones that track upstream sources to the publicly visible server Of course ideally changes should be submitted to upstream, but often available time and resources limit our possibilities. Andris