[evla-sw-discuss] Subversion working directory structure

[bbutler at nrao.edu]

"e2e" is a division.  the actual software, as defined by nicole and agreed
upon by most of us, is divided into 3 areas:
 - M&C (Monitor & Control)
 - SSS (Science Services Software)
 - DPP (Data Post Processing)

and in fact nicole has been trying to get away from the "e2e" moniker, but
hasn't been able to yet.

so i think labelling it as sss rather than e2e is the right way to go. 
whether it is "NRAO-wide SSS", or "EVLA-specific SSS" is a distinction,
but not necessarily one that needs to creep in here.

        -bryan


> 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
>>
>>
>
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>