Subject: Re: Patch naming
To: Gavan Fantom <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 12/31/2003 07:41:42
On Wed, 31 Dec 2003, Gavan Fantom wrote:
> My problem with the current way we do patches is precisely one of revision
> 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.
I agree with that sentiment. When I update patches, I rearrange the
results of "mkpatches", so that "cvs diff" only shows real changes
(and the revision history, after committing, makes sense).
> 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.
If you do as I do, there's no harm in reviving a long-dead patch file
as a different patch.
> It doesn't greatly bother me whether patches are kept in a single file or
> multiple files,
Eh? If you put all patches in a single file, it'll be practically
impossible to get anything useful out of CVS. That's at odds with the
rest of your position.
> 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
> 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.
How about if just we let "mkpatches" match up filenames and preserve