[evla-sw-discuss] Subversion working directory structure

John Benson jbenson at nrao.edu
Mon Nov 13 12:56:17 EST 2006


I would suggest the the 'sss' node revert to 'e2e'. The 'sss' is local, 
the 'e2e' is observatory wide and
that is what some of the software is : archive, proposal tool, user db 
tool.

John

Rich Moeser wrote:
> Brian Truitt wrote:
>   
>> This is correct. I think it's a good idea. My only question now would be 
>>    do we really want or need all the extra trunk directories that could 
>> be created?
>>
>> What I would like is something like:
>>
>> nrao/
>>    sss/
>>      opt/
>>        trunk/
>>        tags/
>>        branches/
>>
>> etc.
>>
>> This alternative seems clunky:
>>
>> nrao/
>>    tags/
>>    branches/
>>    trunk/
>>      sss/
>>        tags/
>>        branches/
>>        trunk/
>>          opt/
>>            trunk/
>>            tags/
>>            branches/
>>
>>
>> The problem is that there are maven configuration files in the 
>> directories above the project level (so we can build all the EVLA 
>> software at once and put snapshot versions of their jar files in our 
>> maven repository on a regular basis.)
>>   
>>     
> I think the solution to this is to have the following structure:
>
> nrao/
>        tags/
>        branches/
>        trunk/
>                 pom.xml
>        evla/
>              tags/
>              branches/
>              trunk/
>                        pom.xml
>              proj1/
>              proj2/
>              proj3/
>              ....
>              projn/
>           
>        sss/
>              tags/
>              branches/
>              trunk/
>                        pom.xml
>              proj1/
>              proj2/
>              proj3/
>              ....
>              projn/
>
>        vlba/
>              tags/
>              branches/
>              trunk/
>                        pom.xml
>              proj1/
>              proj2/
>              proj3/
>              ....
>              projn/
>
> With this structure the only items that are version-ized below the 
> directories nrao, nrao/xxxx are the pom.xml files, which are only used 
> by the build process. Developers would simply checkout their project 
> code using "svn checkout 
> file:///home/asg/svn-repo/nrao/evla/proj1/trunk   proj1", ignoring the 
> trunk/tags/branches directories at nrao and evla.
>
>   
>> This feature may not really be necessary. If you're developing an app 
>> that has a dependency that you are also developing (so you depend on the 
>> "snapshot" version, not a standard released version), you can build that 
>> snapshot and install it in your local repository (located by default in 
>> ~/.m2) and things will work just fine I think.
>>
>> Then it would be up to each individual project to install their 
>> artifacts when appropriate in the site repository (/home/asg/.maven). I 
>> think this would get rid of any extra files sitting outside the project 
>> directories and thus we wouldn't need to have trunk, tags, and branches 
>> directories at those levels.
>>
>> Is that reasonable? If so, I think that would be a good way to go.
>>   
>>     
>
> IMO we need to have the latest snapshots automatically built each night 
> and put into the repositiory. I don't  think we should depend on 
> developers to do this.
>
>   
>> I'll also put a vote in for renaming/removing some of the "commons" 
>> directories as long as we can come up with better names. Otherwise, why 
>> bother? It's not a mortal sin or anything. It may not be perfect, but if 
>> we don't have real good alternatives, I'd rather take a path of least 
>> resistance on this topic.
>>
>> Brian
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>>   
>>
>>     
>
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>
>   




More information about the evla-sw-discuss mailing list