dslinux/lib/flnx CHANGES COPYING ChangeLog Makefile config.h
Amadeus
amadeus at iksw-muees.de
Fri Aug 25 15:40:39 CEST 2006
Stefan,
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?
regards
Amadeus
--
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