bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

new branch


From: Paul Edwards
Subject: new branch
Date: Wed, 05 Nov 2003 10:34:58 GMT

I think my previous posts have not been very constructive.
Sorry about that.  I started reading "How to Win Friends
and Influence People", but I was interrupted by a bug
report and haven't resumed reading since.  :-)

I realised later that the solution was obvious all along.
For whatever reason, there is a "need" for a new branch,
with different specifications to cvs 1.11.x.  This is no
different from normal production support.  The solution
is equally obvious.  You use CVS's brilliant branch
support, and merge in fixes from one branch, onto another
branch.  Indeed, the facilities are so sophisticated that
you don't even need to be in the same repository, that's
what export and import are for.

That's what I've been telling people at work too.  It doesn't
matter if a single individual refuses to use CVS, and it
doesn't matter if management insists on using PVCS for
production code.  It can all be worked around.

In this case, I understand why people would not want to
have 200 different configuration files for all the different
supported platforms, when a utility (run by the user) can
auto-generate them, if they obtain the appropriate tools and
set them up properly.

I also understand why others would prefer to have source
files and a compile procedure that can definitely be run on
their environment.  And how for others, a "project file"
for their compiler is what makes the difference between
being able to fix bugs or not.  And why people go to the
effort of putting an OS/2 port available on an OS/2 site,
and Tandem users put a port on their site.  Unfortunately
these are always out of date.

I understand why sanity.sh tests are good and why they are
requested.

I also understand that you shouldn't look a gift horse in the
mouth, and if someone submits a bug fix, I'd rather have that
fix in the code, and passing the existing sanity checks, than
keeping the bug in the code, because no new sanity check was
provided.

It is not that one philosophy is right and one is wrong, it is
that they are different requirements, in the same way that
1.11.x and 1.12.x are different requirements.  It is perfectly
natural, and that is why god created branches.

As such, I'm planning on starting a new CVS branch, which
has simple compile procedures for the different environments,
relying only on tools that are native to those environments.
Some of those environments will be abstract, e.g. "any C89
compliant environment" or "any Posix 1003.1 environment".

I intend the code to perfectly track the 1.11.x official release,
so that it can be properly understood.  I'm just going to add
a string after it, called "hacked" or "portable" or "extra" or
something like that.

I intend to go and get the emx-new etc from places like
http://shaun.tancheff.com/os2/cvs/
and
http://www.itug.org/member/ituglib/user/toc.cfm
and just incorporate the changes that I see others making.
One day, when I need to go to those environments, I will
be pleased to know that I have source code that natively
compiles.

Any comments?  I was going to host the source code at
sourceforge.net, in a directory parallel to my PDOS
project, which has already been set up, so minimal
fuss.

BFN.  Paul.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]