On Tue, 30 Dec 2003, Ben Collver wrote:

> For the purpose of revision control, NetBSD uses a separate patch file
> for each file that is changed.  I suspect this is the good reason to
> have multiple patch files, and patch-?? is a convenient way to have
> multiple file names.
>
> I would prefer games/falcons-eye/patches/patch-bi over an OpenBSD style
> games/falcons-eye/patches/patch-win_jtp_gamedata_config_jtp_keys_txt any
> day.

My problem with the current way we do patches is precisely one of revision
control.

Patch files keep moving around. If you have a patch for configure, there's
no guarantee that it will keep the same filename for its whole life. Some
people automatically regenerate all the patch files when they change
something, which shuffles them up "neatly". This is a big timesaver, but
leaves the patch files moving around, and makes revision history hard to
follow at best.

Also is the issue of removing patches. We cvs rm patches when we're
finished with them, and cvs add new (unrelated) patches with the same
filename later. Again, revision history is hard to follow.

It doesn't greatly bother me whether patches are kept in a single file or
multiple files, but I do care that if they are kept in multiple files,
that there be a way to statically map the file being patched to the
filename of the patch file. Be this by filename, md5 or an allocation
table I don't care, but it must be automatable (for the people who regen
patches).

Just a final point worth noting - the infrastructure as is doesn't really
care too much whether there's one patch file or plenty, or what they're
called - we just need to change the documentation and any automated
patch-generating tools to implement any change in policy.

-- 
Gillette - the best a man can forget