dslinux/lib/flnx CHANGES COPYING ChangeLog Makefile config.h
stsp at stsp.in-berlin.de
Fri Aug 25 14:44:04 CEST 2006
On Thu, Aug 24, 2006 at 09:09:36PM +0200, Amadeus wrote:
> On Thursday 24 August 2006 17:17, Stefan Sperling wrote:
> > Just checking: you are aware of the branching for third party
> > apps? Remember? ;)
> Oh why have I suspected that you would ask this?
> Yes, I am aware - but I have decided against.
> The cause is that I have decided to break the directory and makefile
> structure of flnx/pixil, and do a massive reordering.
So? This is a huge modification, and cvs should be able to track it.
Not creating a branch may make things easier for you now, but see below...
> So the
> comparision against the original is pointless, giving the restrictions
> of CVS.
The point is not about comparing the sources *now*.
The point is that if you ever want to upgrade to a new version
of upstream flnx/pixil sources (in say, a year's time), it
is easier if you have the unmodified original around *in CVS*.
If you have the original version on a branch, you can do
the following to upgrade:
* checkout flnx_branch head
* apply unmodified diff against unmodified new version
* commit on flnx_branch
here comes the magic:
* checkout head branch
* have cvs merge all new code form flnx_branch
into head *almost automatically*.
Any line that was changed by us will be left intact
if upstream did not modify it, or will trigger a
conflict if upstream did modify it
* in case of conflicts, clean them up
* commit on head
If you don't have original sources to reference, you will not
be able to know which changes were made by you or other comitters
and which code has been unmodified by us but has been modified
by upstream flnx developers. All changes will look the same.
All information you have is whatever code is currently in the
dslinux version, not where it is coming from. You can of course
get this information by downloading whatever version your original
port of flnx was based on, and look at the diff between the sources
in dslinux cvs and the original ones.
However, this already sounds like a lot of work. Now imagine tree
years have passed and 3 versions of flnx have been imported since,
and you want to import another (fourth) version - telling apart
their changes from our changes becomes nearly impossible without
a lot of manual work. The whole thing will become a maintanence
nightmare. Creating the branch takes 3 commands. It does not take
long, and it can save all of us an awful lot of time later!
Also, while you may be able to track your changes in your head,
other comitters do not know what exactly you did, and cannot
even look at it since there is no indication what version of
flnx your port has been based on, nor are convinient commands
like cvs diff usable since you have no base line to compare to
At a last point, consider consistency. If we treat third party
code the same way everywhere, future comitters will be able
to jump in and say "I'm gonna upgrade that flnx library, no
matter whether amadeus is now on holidays and I cannot reach him."
Easy if you have that branch around. A headache if you don't have it.
> There is no much movement in the pixil sources, anyway.
You may still want to merge new versions nonetheless.
http://stsp.in-berlin.de PGP Key: 0xF59D25F0
More information about the dslinux-devel