On Fri, Jan 13, 2012 at 12:06 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: > On Thu, Jan 12, 2012 at 12:26 PM, Les Mikesell <lesmikes...@gmail.com> wrote: > >>> Another option is to store binaries in a separate repository that you can >>> archive and recreate monthly or quarterly, or whatever. Then you can use >>> externals in your projects to reference them. >>> >> >> Is there a 'best practices" kind of writeup on how to do this >> correctly anywhere? We have a lot of component libraries that we >> want to include in larger projects without recompiling each build >> (i.e. we want to run known/tested instances) and have been including >> the binaries in tags so the headers and shared libs are versioned >> together. It''s clearly the wrong thing to do, but it works. How >> can you enforce getting exactly the right things in a parallel >> repository that has only the headers and libs that will work the same >> way for external references? > > You use git, which supports tracking local changes without verbosely > propagating them to the central, canonical repository. This especially > applies to testing binaries, and can be integrated with the git/svn > toolkit to propagate to a more familar and existing central > repository.
Not what I want. I want a central canonical svn repository with tagged versions of matching headers and shared libs that can be predictably accessed with svn externals, I just don't want it to be the same svn repository that holds the source until subversion gets some features that make it feasible to remove things. But I'd like a way to ensure that the tags stay precisely in parallel to the matching source. I don't see how git would help with that part. -- Les Mikesell lesmikes...@gmail.com