On Fri, Jan 13, 2012 at 1:15 AM, Les Mikesell <lesmikes...@gmail.com> wrote: > 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.
You run the testing cycle on a local git working copy, where local changes can be made, recorded, and discarded. You then push the binaries, when needed, to the Subversion repository. Most binaries in an auto-build or development environment are not worth keeping. This allows you to publish only those binaries that you *want* to be reference binaries, in a more flexible fashion than most Subverson repositories, especially because the working local branches and tags need never be published to the main repo and clutter it up. I've used this successfully for environments where a central Subversion reository was mandated by policy, history, or the desire for centralized source control.
