[Zope3-dev] The Zope Software Certification Program and Common Repository Proposal

Dominik Huber dominik.huber at perse.ch
Thu Feb 23 15:02:03 EST 2006


Stephan Richter wrote:
> On Wednesday 22 February 2006 10:58, Dominik Huber wrote:
>   
>> Do you have an other solutions for this problem?
>>     
>
> Honestly, I had not thought about this case, but it is clearly a valid use 
> case.
>
> What about this structure?
>
> repos/main/
>     NAMESPACE/
>         branches/
>         tags/
>         trunk/
>             ...configure stuff here...
>     NAMESPACE.PACKAGE1/
>         branches/
>         tags/
>         trunk/
>     NAMESPACE.PACKAGE2/
>         branches/
>         tags/
>         trunk/
>
> [...]
>
> What do you think? I think this is the right way to do it, since it is a very 
> logical procedure to flatten the namespace tree.
>   
We came up with the same solution first. But our problem appears within 
the following use case.

A few developers are sharing code on application level (not  package 
level!) for different dedicated customer projects. They have problems to 
setup identical dev-environments (packages with the same revisions 
etc.). So they want setup a dedicated application repository that brings 
different packages together using the svn:externals excessively. In the 
end developers should check-out this application repository (comparable 
to the Zope3/trunk) for joint development on application-level. The only 
way they could set the svn:externals-property using the above layout is 
the following:

repos/main/
    APPLICATION1/
        branches/
        tags/
        trunk/
            src/
               -> svn:externals: NAMESPACE url
               -> svn:externals: NAMESPACE/PACKAGE1 url
               -> svn:externals: NAMESPACE/PACKAGE2 url

This scheme will work, but we have the disadvantage that they still cannot share application-specific configurations of NAMESPACE for further customer projects because they cannot link repos/main/APPLICATION1/trunk/src/NAMESPACE via svn:externals.

The solution we came up was to put the '...configure stuff here...' *files* of the NAMESPACE not directly into the namespace itself, but in a dedicated *folder* for example 'configure':

repos/main/
    NAMESPACE/
        branches/
        tags/
        trunk/
            configure/
               ...configure stuff here...

That way we can move the svn:externals to the NAMESPACE folder of the APPLICATION1 repository: 

repos/main/
    APPLICATION1/
        branches/
        tags/
        trunk/
            src/
               NAMESPACE/
                 __init__.py
                 -> svn:externals: configure url
                 -> svn:externals: PACKAGE1 url
                 -> svn:externals: PACKAGE2 url

This enables the developers to share this NAMESPACE configuration for further customer projects for example the following PROJECT01:

repos/main/
    PROJECT01/
        branches/
        tags/
        trunk/
            src/
              -> svn:externals: NAMESPACE url*

*url = repos/main/APPLICATION1/trunk/src/NAMESPACE

Did you catch our purpose? We think that could simplify joint development. So we might include such a 'configure-folder' convention or 'never-put-any-configure-stuff-inside-a-namespace' rule in the ZSCP and CRP-proposal.

Regards,
Dominik




More information about the Zope3-dev mailing list