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.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2012-01-13 07:16:59 CET