On Fri, Jan 13, 2012 at 1:15 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Fri, Jan 13, 2012 at 12:06 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>> On Thu, Jan 12, 2012 at 12:26 PM, Les Mikesell <lesmikesell_at_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.
Received on 2012-01-13 07:28:32 CET