> > If you need to control access to the code you can do things such as:
> > - only allow the developers that need access access to the whole project
>
> Yep, we do this. There are still some restricted areas in some projects
> though.
>
> > - setup a secondary tags namespace for special binary only information
> > - have the build mechanism push the binaries to a special binary tag by
> the
> > same
> > name
> > - use svn:externals to reference the binary releases instead of source
> > releases.
>
> Yes, I think binary releases of restricted modules is a very good idea.
> It's
> a slow process, but I think pushing for this will help a lot. There's a
> perception that binary releases of restricted source code is not necessary
> if product-specific changes are needed to the code. Just copy the source
> code to the product folder and restrict it in httpd.conf. I'm working on
> this... Also, while we don't use svn:externals currently, it looks like
> it would be useful for handling binary releases of restricted code. Thanks
> for that!
Let me try to say that a bit better. Binaries are always created for the
restricted source code. The need to include the restricted source code in
the product directory is debatable. Treating the restricted source code as
a full-fledged project with it's own top-level directory would help. If a
product-specific change is needed to the restricted code, create a branch
under it's directory, store the binary during release, and reference the
binary in the product folder with svn:externals. That's a bit more clear,
I think.
Received on 2010-10-13 23:05:05 CEST