Re: [Gnu-arch-users] Re: [BUG] Re: False "binary" files

[Adrian Irving-Beer]

On Mon, Feb 14, 2005 at 08:09:10AM -0500, Stefan Monnier wrote:

> From a revision-control point of view, putting the diff/patch code
> in the same branch as the project sounds like bad practice.  I
> suspect security problems would be dwarfed by more immediate
> concerns.  E.g. it would probably also suffer from bootstrapping
> problems (how do you do the first check out?).

AFAICT, you do it by getting the latest import copy / cacherev, which
are free of diff/patch issues.

After that, as long as the code is introduced before changesets
that use it, you can continue to do things the way the tree says to
do them.  You would have to reread the config for every patch
applied, though.

Plus like =tagging-method, it's possible to commit a change to
patching in the same patch that actually uses that new patching
method.

Unlike =tagging-method -- where the next inventory doesn't need occur
until *after* the new method is in place -- this will cause problems
for diff/patch, since you need to know how to handle a patch before
you actually handle it.  And if that patch is what updates the
handling instructions, then it's a catch-22.

All this is circumvented if the patch instructions are included as a
part of each changeset, though.  But that means the *methods* need to
be coded into the client's 'tla', and the instructions simply say what
methods apply to what files.

Aside from the security implications, if you used binary patch utils
in the above system, you'd have to duplicate the binary for every
single changeset.  Even in a stripped, compressed binary, this would
add up quickly.

This is all as I understand it, of course.

signature.asc
Description: Digital signature