On 8 Feb 2013 17:51, "Les Mikesell" <lesmikesell_at_gmail.com> ...
> >
> > Separate repositories linked together by "svn;external" settings can
> > do this, with a central "build" structure publishing tags or branches
> > with hooks to specific releases of components from other repos. But
> > resource tracking can get awkward. Some old legacy repo that only one
> > project was using can wind up culled, with managerial approval, and
> > discovered to be critical to another legacy tool or two that no one
> > has built for a few years and kept saying "if it's not broken, don't
> > fix it". So factoring the repositories well, and having good archival
> > backups, can be invaluable.
>
> You can simply put a bunch of repos under the top level served by http
> or svn and it appears pretty seamless except for when you have to
> create a new one. But, since binary diffs aren't very useful anyway
> and that migh have scaling issues, I think I'd just try to use a
> de-duping filesystem like zfs and store as many copies as ...
The requirement is more about trackabiliy; knowing where in the workflow
the binary file is. I don't think anyone is expecting to use diffs but the
history would be key.
Thanks,
Dermot.
Received on 2013-02-08 20:14:33 CET