> an obvious problem with that approach is that executable content (i. e.
> "command-lines") is automatically downloaded and executed on a simple
> checkout operation. That's a big security risk and something I wouldn't
> want to see in any RCS.
Agreed. Also it's crucial that the patch and diff used to build up the
internal deltas used to store patches in the archive be perfect inverses of
each other.
E.g. using "diff -b" is not an option, even for files for which changes in
whitespace is not significant.
In other words, the compression of patches (based on diff) should be lossless.
With such constraints, there really aren't many different diff/patch tools
available: traditional patch&diff, xdelta, and variants thereof.
Now people will want more flexibility (e.g. structural diffs for XML data)
and we could do something like that by having some kind of canonicalization
as a pre-processing stage of commit.
It could even look like:
1- SDIFF = structural-diff BASE CURRENT
2- CURRENT = structural-patch BASE SDIFF
3- presumably now that CURRENT has been made "canonical", we have that
structural-patch BASE (structural-diff BASE CURRENT) == CURRENT
So we could then use the structural-diff/patch operations as internal
diff/patch. As you mentioned it may very well be undesirable anyway because
it implies that structural-patch is needed just to checkout the tree.
OTOH I believe that in most cases just doing a good canonicalization should
be enough for a plain line-based diff/patch or xdelta to go a good enough
job, so I still believe that the internal diff&patch operations should be
basically hardcoded.
Stefan
_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
