On Thu, Jan 12, 2012 at 12:26 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Thu, Jan 12, 2012 at 9:20 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>>
>>> Please advise me with good practice.
>>> Your suggestion is more use to me.
>>
>> I think the main way to keep repos small is to NOT put binary files in it. Of course, depending on your usage that may not be practical. I think the majority opinion is hard drives are cheap.
>>
>> I know some people here have recommended some binary versioning systems that only maintains a certain number of versions back and delete older ones. I don't recall the names. Someone else can chime in with one or two.
>>
>> You could also implement something like that yourself with a build script. Store your binaries in a folder tree with a "latest" that is a symlink of the most recent version of the binaries. This way your references and such don't need to change for every version.
>>
>> 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.
Received on 2012-01-13 07:07:23 CET