On Wed, 31 Dec 2003, Gavan Fantom wrote:

> 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.

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
> 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.

How about if just we let "mkpatches" match up filenames and preserve
CVS tags?

Frederick