[evla-sw-discuss] Subversion working directory structure

Brian Truitt btruitt at nrao.edu
Thu Nov 9 18:29:38 EST 2006


> Well ... if I'm reading the subversion book correctly, it appears  
> that the working directory does not need to follow the repository's  
> structure identically.  For example NRAO/EVAL/OBSERVE could be  
> checked out into ~/observe.
> 
> Is this correct?
> 


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.)

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.

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



More information about the evla-sw-discuss mailing list