dslinux/lib/flnx CHANGES COPYING ChangeLog Makefile config.h

Amadeus amadeus at iksw-muees.de
Fri Aug 25 15:40:39 CEST 2006


On Friday 25 August 2006 14:44, Stefan Sperling wrote:
> The point is not about comparing the sources *now*.

I know.

> 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*.

The storage of the unmodified original is valueable, yes.
There is the a version number in the changelog, but I would prefer to 
store the original version in a separate directory (tree).

> 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*.

How, if I break Makefiles and directory structures to fit it into the 
uCLinux build system? This is the major point here - and maybe it's 
doable with SVN which can trace moved files. But CVS?

And what if I have extracted a list of files from a Makefile and 
inserted it into another file? Can CVS patch my target file if the list 
of files in the original is extended?

> 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
> in CVS.

> 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."

This sounds good. But do you have an answer to my problem?

We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

More information about the dslinux-devel mailing list