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

[Jan Hudec]

On Mon, Feb 14, 2005 at 12:01:04 -0500, Adrian Irving-Beer wrote:
> 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.

No. I believe binaries in the tree should never ever be allowed. There
should a list of tool names with default mapping detected by configure
and linked in the tla binary and additional mappings defineable in
.arch-params. The patch and tle log (yes, it should be in the log, so
it's easy to ask "what tools do I need to check out this branch") should
state list of tools needed to apply that pach (the patch including
mapping files to tools).

> This is all as I understand it, of course.



> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature