> (a) obviously suffers from the problem of supporting old users, maybe
> it would need an archive rev because of that;
Yes, I'm assuming we're going to change the archive format. Maybe it can be
done in a backward compatible way, but I'm not sure it's worth the trouble.
> (b) suffers from the similar problem of making sure users have all needed
> components to use a customized tree and also has security worries if any
> executable scripts end up in archives.
>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?).
> and instead, (b) should just rely on a flexible but declarative
> extension mechanism.
I'd use an indirection: changesets and such would specify "diff/patch/merge"
names, and then users ~/.arch-params would map those names to actual
programs. It seems safer, more flexible, ...
> So a changeset might have a file called "=diff-patch-extensions",
> containing e.g. a list of diff/patch-extension-name / filename-regexp
> pairs:
> arch-ids .arch-ids
> unzip-first .*\.gz
> or something like that.
Since two files with the same extension might use different diff/patch
algorithm (typically if they're in different subdirectories), the changeset
format would probably be better off listing the files themselves.
A regexp table would be in order for .arch-inventory or some such in order
to determine which algo to use when building the changeset, tho.
Stefan
_______________________________________________
Gnu-arch-users mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
