Re: Re: Idea: embed patch in .info

Am Freitag, 11.07.03 um 23:53 Uhr schrieb Daniel Macks:

[...]

> A quick look at unstable/utils finds 20 or so packages where the .patch
> and .info have different rev's as a result of the -dev essentials fix,
> validator fixes, checksum additions, Source changes, typos. So one 
> would
> have to bump the (CVS) rev of a corresponding .patch whenever this
> happens. All-told, about a third of the files there have rev>1.1, 
> meaning
> something has changed without bumping up %v-%r.

You are making the incorrect assumption that files are matched via the 
revisions. That is not true in CVS in general. Rather, you would match 
them via the date, or by release tags. File revisions in CVS should 
*never* be used to match files in CVS. Hence I do not consider your 
argument given above as valid.

[...]

> I agree with the "think long and hard before changing formats". That's 
> why
> the things I had proposed in previous messages were pretty much just
> stringing the current files together (cf. an actual archive format), 
> and
> keeping it transparent and optional.
BTW for everybody who didn't notice; if your patches are short, it's 
already today rather trivial to integrate them into the .info file by 
embedding them into the PatchScript.

> A combination of CVS tagging the .patch with %n-%r and using Patch-MD5 
> (as
> people suggested recently) would solve both sync problems I think? An
> .info could never use a wrong .patch, and one doesn't have to worry 
> about
> keeping CVS rev#s in sync.
Patch-MD5 sounds more acceptable to me than a format change. And 
tagging revisions, well it could be done, but mostly for convenience, 
to make it easier to check out a given ver/rev. -D checkouts will 
already make it possible to get the matching patch.

> Okay, what if we tag .patch, and then change from having the .patch in 
> the
> tree to being something that is downloaded during build?
Bad idea. That would mean you have to have an online connection to 
build; and even if we cache the .patch files like we cache source files 
in /sw/src, it would mean that the .patch files have to have the 
%n-%v-%r.patch name again, and we have to keep all .patch versions ever 
around on our server - after all, not everybody is using latest CVS, so 
we can't just only provide the latest patch as %n.patch.


Cheers,

Max



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1