On Tue, Aug 14, 2012 at 9:05 AM, Leonardo Laface de Almeida
<leonardo_at_sweda.com.br> wrote:
>
> So, three main situations:
>
> 1) When source code from P1 changes module M1, the P2 must have access to
> it, and vice-versa.
> 2) When source code from P1 changes shared code from L1, the L1 source code
> must be actualized, and vice-versa.
> 3) When L1.dll changes, A1, A2 and A3 should automatically start to use the
> new L1 created.
>
>
> I'm still a bit lost here how to share the codes into SVN. I think I may
> create one repository to each one (P1, P2, M1, L1, A1, A2 and A3). The
> problem is doing all svn commands for each one.
>
> For example, If I will change L1, I must to check out P1 and M1 to compile
> it. Then, after changes, I must commit P1, M1 and L1, for source code and
> commit the L1.dll file for A1, A2 and A3. It's unlikelly doing this
> manually.
>
> In other hand, I also think it's unlikelly to create only one repository for
> all these projects.
It doesn't really matter whether each project has its own repository
or not, as long as the shared components each have their own top-level
subdirectory. For each shared thing needed for a build, just use an
svn external reference in the project that needs it to pull it into a
subdirectory of the workspace. If you want to use pre-built .dlls,
you can commit them back as well. For ongoing development you might
let the externals reference the trunk versions of the components, but
you will probably want to establish a naming convention for your
branches and tags from the start. As you approach release versions
of each projects you would normally want to tie the externals to
tagged versions of each component in case the component development
continues in incompatible/untested ways on the trunk.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2012-08-14 17:06:53 CEST