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 <andris DOT pavenis AT iki DOT fi>
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
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

- Raw text -