On 8 Feb 2013 17:51, "Les Mikesell" <lesmikes...@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.
