[Biococoa-dev] BioCocoa Applications

[Scott Christley]

Great!  Yes, the SVN book recommends your Option 1 and that sounds  
good to me too.  Too bad that the Applications directory couldn't be  
made at the root level with BioCocoa, so something like this:

BioCocoa/
	trunk/
	tags/
	branches/
Applications
	MyApp
		trunk/
		tags/
		branches/
	YourApp
		trunk/
		tags/
		branches/


The current command on the wiki:

svn checkout svn+ssh://bioinformatics.org/svnroot/BioCocoa

will currently get everything including all the applications.  But  
with the root split out people could do:

svn checkout svn+ssh://bioinformatics.org/svnroot/BioCocoa/BioCocoa

to get the core framework and

svn checkout svn+ssh://bioinformatics.org/svnroot/BioCocoa/Applications

to get the applications.  But yes, I think you are saying that moving  
around the root directories may cause confusion for older revisions.   
So I agree, not touch the root directory and just add the  
Applications directory

cheers
Scott


On Sep 26, 2007, at 12:23 PM, Charles Parnot wrote:

> SVN is much simpler than CVS, once you understand more of the  
> basics. It is fairly easy to grasp those concepts. I really  
> recommand reading the free SVN book online, particularly the parts  
> explaining the 'philopsophy' of the system.
>
> By convention, and because it works well this way, you want to have  
> a 'trunk', a 'tags' and a 'branches' directory for each project.  
> The current svn tree is:
>
> BioCocoa/
> 	trunk/
> 	tags/
> 	branches/
>
> I would not recommand changing that too much (though svn makes that  
> easy, it might still be confusing when going back to older  
> revisions). Since the trunk directory contains all the BioCocoa  
> framework code directly, with no other subdirectory, I would not  
> recommand having the apps in there.
>
> Instead, I would suggest adding an additional directory under the  
> root, called Applications:
>
> BioCocoa/
> 	trunk/
> 	tags/
> 	branches/
> 	Applications/
>
> Then, you have these 2 options:
>
>
> *Option 1:
>
> BioCocoa/
> 	trunk/
> 	tags/
> 	branches/
> 	Applications/
> 		MyApp/
> 			trunk/
> 			tags/
> 			branches/
> 		YourApp/
> 			trunk/
> 			tags/
> 			branches/
>
> *Option 2:
>
> BioCocoa/
> 	trunk/
> 	tags/
> 	branches/
> 	Applications/
> 		trunk/
> 			MyApp/
> 			YourApp/
> 		tags/
> 			MyApp/
> 			YourApp/
> 		branches/
> 			MyApp/
> 			YourApp/
>
> I would have a slight preference for Option 1, but it really does  
> not matter that much, and there is no technical reason that I  
> foresee why one option is better than the other. You might give it  
> more thoughts, and maybe there would be some technical reasons why  
> one option is better than the other.
>
> Again, I recommand following the svn convention because: (1) it  
> works, (2) anybody familiar with svn will be instantly confortable.
>
> hope that helps!
>
> charles
>
>
>
>
>
> On Sep 26, 2007, at 8:14 AM, Scott Christley wrote:
>
>>
>> I agree as well.  The question though is how to set up the SVN  
>> repository to support this properly.  I'm more familiar with CVS  
>> than SVN, I understand the concepts of branches and tags but it is  
>> not clear to me how this works with SVN.  I need to read up on this.
>>
>> Preferably people should be able to SVN the BioCocoa core  
>> framework without getting other stuff; likewise with the  
>> applications, they should be able to SVN either all the  
>> applications or just specific ones they are interested in.  Any  
>> ideas on how to set up the repository?  Would the current  
>> repository need to be re-structured to support separate applications?
>>
>> Thinking with my CVS mind, I would consider making the repository  
>> look something like this:
>>
>> trunk/
>> 	BioCocoa/
>> 	Applications/
>> 		MyApp/
>> 		YourApp/
>>
>>
>> thanks
>> Scott
>>
>>
>> On Sep 24, 2007, at 5:53 PM, Charles Parnot wrote:
>>
>>>>
>>>> What do people think about creating a source repository with  
>>>> community donated applications that use BioCocoa?
>>>>
>>>> I'm thinking that having the BioCocoa library is great, but  
>>>> still people are required to write their own applications on top  
>>>> of it.  Some could be sample applications, but I suspect that  
>>>> others would be useful full-fledged apps that maybe focus on  
>>>> specific area of analysis, etc.  I certainly have some end-user  
>>>> oriented tools that I would like to provide, but don't have  
>>>> anyplace to put them except create a new project somewhere.
>>>>
>>>> cheers
>>>> Scott
>>>
>>> I agree that there is nothing better than some real-world app  
>>> using the framework, to get the framework in the best shape. A  
>>> lot of design and optimizations in the framework will then be  
>>> triggered by real issues in real apps, not just what we think  
>>> could be better.
>>>
>>> These apps can also serve as extra testing tools, in addition to  
>>> the automated tests that are built in the framework itself.
>>>
>>> charles
>>>
>>> --
>>> Xgrid-at-Stanford
>>> Help science move fast forward:
>>> http://cmgm.stanford.edu/~cparnot/xgrid-stanford
>>>
>>> Charles Parnot
>>> charles.parnot at gmail.com
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Biococoa-dev mailing list
>> Biococoa-dev at bioinformatics.org
>> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
> --
> Xgrid-at-Stanford
> Help science move fast forward:
> http://cmgm.stanford.edu/~cparnot/xgrid-stanford
>
> Charles Parnot
> charles.parnot at gmail.com
>
>
>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20071003/2096c497/attachment.html>