lwip-users
[Top][All Lists]
Advanced

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

RE : [lwip-users] Lots of RAM


From: Frédéric BERNON
Subject: RE : [lwip-users] Lots of RAM
Date: Mon, 10 Sep 2007 09:55:37 +0200

Hi,

I don't see like something difficult to work with ONE more line in a diff,
but, as it seems cause you problems, and if anyone else "push" this idea,
we can abandon it. But what Tim do when it add a version inside his files
distribution, is not always do by other "integrators", so, lot of users
don't really know on which lwIP release the code they used is based (and
it don't help us to know if a bug is already fixed or no).

>"the fairly unusual organization of the lwip code"

What will be a better organization of the lwip code to your point of view?

> The correct answer to this is either A) use/learn how to use a better
> editor/IDE/whatever for computer work or B) use a better 
> prettyprinter/CVS browser/etc. for hardcopy/web display.

I suppose it's a joke, so, no comment :)
 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Timmy Brolin
Envoyé : lundi 10 septembre 2007 00:51
À : Mailing list for lwIP users
Objet : Re: [lwip-users] Lots of RAM


I agree.
At work we have all the version history information in the repository. 
Nothing in the source files.
There are however a few exceptions when version information in soruce 
files can be useful. When we release source code externally, our 
external partners/customers obviously do not have access to our internal 
repository, so we add version information at the top of each file in the 
release.
I guess it would be possible to do something similar with lwip. Keep the 
source files clean in the repositoy, but add version information to the 
source files in the tarball releases?
That way developers who use the repository don't have to put up wiht the 
version nonsense at the top of each file, and people who prefer to get 
their sourcecode from the release tarballs get some version inormation 
in their files.

/Timmy

Andrew Lentvorski wrote:

> Frédéric BERNON wrote:
>
>> I'm agree with Jonathan & Simon (but I think we should add $date$ and
>> $revision$ CVS keyword, is there any objections to add them ?).
>
>
> I object.  Strenuously.
>
> It's already tough enough to mesh the fairly unusual organization of
> the lwip code with other projects as well as track upstream changes.  
> Adding CVS keywords is going to make diffing unnecessarily annoying.  
> If you must, at least put them at the *bottom* of the file.
>
> The source code is your gold standard.  Your repository is where all
> the metadata for you source code goes.  The two should not meet.
>
> The whole "CVS keyword" problem is why you need weird "Oh, leave this
> file alone" flags so that CVS doesn't do keyword interpolation (want 
> to check in a tar file?  oops.  Have a script that looks for CVS 
> keywords?  Oops.)
>
> There are lots of CVS annotation tools that exist.  Most of them are
> *far* more informative than any meager amount of information a CVS 
> keyword could convey.
>
> The correct answer to this is either A) use/learn how to use a better
> editor/IDE/whatever for computer work or B) use a better 
> prettyprinter/CVS browser/etc. for hardcopy/web display.
>
> The wrong answer is modifying the checked in code.
>
> If the problem, however, is: "I can't do CVS operations when offline."
> then the solution is to upgrade to a better source control system.
>
> This objection comes from the fact that I actually check out lwip from
> CVS and then check it right back into my mercurial repository 
> (mercurial is much nicer when trying to merge upstream changes than 
> CVS).  I can think of several things that will likely break if 
> keywords get added to the mix.
>
> -a
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden 
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>


_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Attachment: Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf


reply via email to

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