How best to use externals for handling sensitive vendor library?

[David Aldrich <Da...@EMEA.NEC.COM>]

Hi

We develop a Visual C++ project that, in one project configuration, uses a small vendor library that is subject to export control.  This means that we can't let all developers on the project see that library.  Everyone can build with some build configurations but only some developers can build with that sensitive configuration.

The project source code is stored in a dedicated svn repository.  We have chosen not to store the vendor library with our source code because we don't want the hassle of maintaining svn permissions for the library across trunk and branches.  So we just instruct the developers who need the library to unzip the library straight into the working copy.  This is inelegant and I am looking for a better solution.

I guess the obvious solution is to use a 'svn external' to retrieve the vendor library from another svn repo or project.  We can then tighten the permissions on the vendor library svn project.  But what would happen to developers of the main project if they couldn't access the vendor library?  Would the external reference fail gracefully or would the checkout fail?

I would be grateful for suggestions on how best to handle this problem.

Best regards

David

Re: How best to use externals for handling sensitive vendor library?

[Torge Riedel <to...@gmx.de>]

Another approach is to import the libraries into a vendor branch in your project including the header files and everything else required for build. Every time this protected library is rebuild you import the bins again into the vendor branch. It is a good advice to always create a new folder in SVN for each version:

/vendor/my_company/protected_lib/0.1
/vendor/my_company/protected_lib/0.2
/vendor/my_company/protected_lib/0.2.1

In your external you reference a specific version. This does not mess up your tags if you import a new version.

Torge

Am 24.03.2014 14:06, schrieb Markus Schaber:
> Hi, David,
>
> Von: David Aldrich [mailto:David.Aldrich@EMEA.NEC.COM]
>> We develop a Visual C++ project that, in one project configuration, uses a small vendor library that is subject to export control.  This means that we can't let all developers on the project see that library.  Everyone can build with some build configurations but only some developers can build with that sensitive configuration.
>
>> The project source code is stored in a dedicated svn repository.  We have chosen not to store the vendor library with our source code because we don't want the hassle of maintaining svn permissions for the library across trunk and branches.  So we just instruct the developers who need the library to unzip the library straight into the working copy.  This is inelegant and I am looking for a better solution.
>
>> I guess the obvious solution is to use a 'svn external' to retrieve the vendor library from another svn repo or project.  We can then tighten the permissions on the vendor library svn project.  But what would happen to developers of the main project if they couldn't access the vendor library?  Would the external reference fail gracefully or would the checkout fail?
>
> Each checkout and update will by itself complete, but return a non-zero error code and error messages due to the failed external reference.
>
>> I would be grateful for suggestions on how best to handle this problem.
>
> In my eyes, the obvious solution is to fetch the vendor library via the build scripts (in exactly those configurations which need it). If your build mechanism does not have integrated SVN support, you can just use "svn checkout / svn update" commands via shell, depending on whether the directory already exists or not.
>
> Best regards
>
> Markus Schaber
>
> CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
>
> Inspiring Automation Solutions
> ________________________________________
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.schaber@codesys.com | Web: codesys.com | CODESYS store: store.codesys.com
> CODESYS forum: forum.codesys.com
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>

AW: How best to use externals for handling sensitive vendor library?

[Markus Schaber <m....@codesys.com>]

Hi, David,

Von: David Aldrich [mailto:David.Aldrich@EMEA.NEC.COM] 
> We develop a Visual C++ project that, in one project configuration, uses a small vendor library that is subject to export control.  This means that we can't let all developers on the project see that library.  Everyone can build with some build configurations but only some developers can build with that sensitive configuration.

> The project source code is stored in a dedicated svn repository.  We have chosen not to store the vendor library with our source code because we don't want the hassle of maintaining svn permissions for the library across trunk and branches.  So we just instruct the developers who need the library to unzip the library straight into the working copy.  This is inelegant and I am looking for a better solution.

> I guess the obvious solution is to use a 'svn external' to retrieve the vendor library from another svn repo or project.  We can then tighten the permissions on the vendor library svn project.  But what would happen to developers of the main project if they couldn't access the vendor library?  Would the external reference fail gracefully or would the checkout fail?

Each checkout and update will by itself complete, but return a non-zero error code and error messages due to the failed external reference.

> I would be grateful for suggestions on how best to handle this problem.

In my eyes, the obvious solution is to fetch the vendor library via the build scripts (in exactly those configurations which need it). If your build mechanism does not have integrated SVN support, you can just use "svn checkout / svn update" commands via shell, depending on whether the directory already exists or not.

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH 

Inspiring Automation Solutions 
________________________________________
3S-Smart Software Solutions GmbH 
Dipl.-Inf. Markus Schaber | Product Development Core Technology 
Memminger Str. 151 | 87439 Kempten | Germany 
Tel. +49-831-54031-979 | Fax +49-831-54031-50 

E-Mail: m.schaber@codesys.com | Web: codesys.com | CODESYS store: store.codesys.com 
CODESYS forum: forum.codesys.com 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915