On Wed, 31 Dec 2003, Frederick Bruckman wrote:

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

Sure, but when combined with patch files moving around at random it
becomes difficult to tell whether this is a new patch, or a patch that has
been moved.

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

On the contrary, while you may not get *as much* out of CVS, you still
have plenty more than the current situation. Patches are still being added
and removed, one change, one commit. The log messages still make sense,
and aren't full of shuffling files around. Inserting a patch into the
middle of the file is a fairly normal cvs operation. And to top it all
off, cvs annotate still gives useful results.

For me this is good enough, and certainly a substantial improvement on
the present situation.

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

That would be a significant improvement.

-- 
Gillette - the best a man can forget