[Biococoa-dev] Re: Subversion proposal
Charles Parnot
charles.parnot at gmail.com
Mon Mar 6 16:41:19 EST 2006
Sorry, I seem to spread confusion...
I would not make BCStandalone part of the Trunk. Trunk should only
contain the files that are actually really part of the Xcode project,
otherwise that would be confusing. Also, BCStandalone is not
conceptually code that belongs to the Trunk: it is not code that is
being worked on for the next version of BioCocoa (instead, some of
the code might be merged into the trunk). The trunk should only
contains code for version 2.0. Alex's stuff definitely belongs to the
"Tags" directory, as being a "frozen" version of some side project. I
am not sure we should modify that independent code too much, but if
we do, we would start a branch (Branch 1.x). But again, it is
probably not something we should do. Instead, we would merge the
useful code in the Trunk, where it belongs, and go from there (e.g
KDTExtView --> svn copy into Trunk/BCAppKit/BCTExtView).
I think the way a subversion layout is supposed to be organized is:
* Trunk = only the latest version = BioCocoa future 2.0
* Tags = finished versions, one directory per version; for instance,
"BioCocoa 1.6" should be one such directory; the contents of the
"Tags" directory is never modified, only new directories added for
each new version (this is just a convention, of course; the "Tags"
directory does not magically prevent modifications; only by
convention, you should never commit a new version of a file in the
Tags directory)
* Branches = if one wants to update an older version, a branch can be
created; for instance, we may want a "BioCocoa 1.x" branch if we want
to modify BioCocoa 1.6 and be able to commit changes, until it is
stable and reaches "1.7"... at which point we use svn copy to add a
directory to the "Tags". Just in case some of you don't know how svn
works: making a svn-copy of a full directory does not create any
files; it is merely creating an pointer to that version and not using
any disk space. It is a very easy to create regular snapshots of the
code as things go along, with numbers, e.g. "BioCocoa 2-beta1",
"BioCocoa 2-beta2", "BioCocoa 2-beta3",...
Besides that, your email makes sense. The other confusion I spread
was that to me, BioCocoa 1.7 = version following BioCocoa 1.6, which
should be your code updated with the new BCReader code, and maybe
including Alex's AppKit stuff, all in the Tags directory.
The bottom line is: somebody interested in using stable code, would
go in the Tags, and pick which version she wants, and check out that
version. Somebody interested in development would check out the Trunk
and work on the latest version. Somebody interested in merging the 2
would check out both, and copy/paste codes between the 2. Or, in the
case of KDTextView, use svn-copy to get the code from the BioCocoa
1.7 tag into the trunk, with its new name BCTextView.
I hope I explained things better, this time!
charles
On Mar 6, 2006, at 12:23 PM, Peter Schols wrote:
> Hi Charles and Alex,
>
> I'm almost getting it... still a bit confused with all those names
> though ;-)
> To me, BioCocoa 1.7 == Alex's code == BCAppkitStandalone. At least
> to me these three items point to the same thing: the ready-to-use
> code that Alex announced yesterday.
>
> I think Charles has a point to include this code in the repository
> so we can easily improve it. Here is what I'm proposing now:
> - I checked out the latest CVS version (I finally got it to work,
> it seems like bioinformatics.org does not keep your account
> password in sync with your CVS password)
> - I removed all CVS folders (including those in bundles)
> - I upgraded the project to the latest version of Xcode (2.2) and
> built it to make sure it works
> - I removed the .pbproj file
> - I linked to the Mac OS X 10.3.9 SDK because I did not have any
> previous SDKs installed. I guess Mac OS X 10.3.9 should be a good
> minimum target by now.
> - I added a new folder to the root of the BioCocoa folder, on the
> same level of BCAppKit, ... This new folder is called BCStandalone
> (another new name ;-)) and contains all great code Alex has posted
> yesterday. I chose the name BCStandalone because it does not only
> contain AppKit code but also new reader classes which are more
> BCFoundation-like.
>
> As far as I can tell this structure is ready to be imported into
> our SVN rep. Please let me know if you all agree with this approach.
> Of course, we can always add new folders later. For now, the
> hierarchy would be:
>
> - Trunk
> - BC.icns
> - BCAppKit
> - BCFoundation
> - BCStandalone
> - BCStringDefinitions.h
> - BCStringDefinitions.m
> - BioCocoa_Prefix.h
> - BioCocoa.xcodeproj
> - Copying.txt
> - DeveloperDocs
> - Documentation
> - Examples
> - Info-BioCocoa.plist
> - main.c
> - Readme.txt
> - Resources
> - Tests
>
> - Tags
> still empty
>
> - Branches
> still empty
>
> cheers,
> peter
>
>
> PS: Now that I see this hierarchy, shouldn't we move the
> BCStringDefinitions files to the BCFoundation folder? And the
> BC.icns to the Resources folder, as well as the .plist file? That
> should keep the root nice and clean.
>
>
> On 06 Mar 2006, at 20:54, Charles Parnot wrote:
>
>>> Hi Charles,
>>>
>>> If I get you right, you would prefer option 3, so you'd move the
>>> "AlexCode" to a separate folder in the trunk?
>>> I'm a bit confused... sorry
>>>
>>> Peter
>>
>> Well, actually, it seems like I do, though I did not really
>> realize :-)
>>
>> My point is simply: Alex's code is being used in 1-3 "stable"
>> applications, and will thus be tested and used quite a lot. Such
>> code is very valuable and should be included "as is" in the
>> repository. I realize now that you want to avoid "extra" code
>> outside of the BioCocoa stuff. So, at least, BioCocoa 1.7 could be
>> included. Including the other "goodies" may or may not make sense,
>> and may or may not make things more confusing. However, maybe
>> restricting it to a particular subdir in the Tags directory is
>> still OK, as this is the place for "frozen" items. Starting
>> branches with these is probably a very bad idea, and I would
>> actually not include a BioCocoa/Branches/Goodies directory, shame
>> on me!
>>
>> All of this also depends how you can bundle things. If the new
>> BCReader integrates well with BioCocoa 1.6, then we should
>> definitely make a BioCocoa 1.7 with it. Regarding the other
>> extras, we could bundle them with BioCocoa 1.7, or keep them
>> separate (Goodies), or not include them. Again, if they can be
>> bundled easily and transparently with it, then we should do it, so
>> the good code is there on the repository.
>>
>> Alex, what do you think? In your email, you proposed:
>>> Also, I think its time to update the BioCocoa website to
>>> represent this all.
>>> It should give a general introduction of who we are and what we aim.
>>> It should describe the current stable releases (BioCocoa 1.6 +
>>> "BCAppkitStandalone", with links to download etc
>>> It should describe our current plans on developing BioCocoa 2.0 -
>>> > give some ideaof what we want and info on how to join, access
>>> the svn server etc.
>>
>> but did you mean to have BioCocoa 1.6 + "BCAppkitStandalone"
>> available on the svn server?
>>
>> In the end, don't worry too much about what I say, Peter: do what
>> you think is best. Anyway, we can always decide to add stuff
>> later, and start with some minimal layout for now.
>>
>> charles
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> On 06 Mar 2006, at 18:49, Charles Parnot wrote:
>>>
>>>> I don't think we need 2 repositories. Subversion is very
>>>> convenient for branches and tags. I think Alex's final code
>>>> should be included "as is" in the current svn directory, as a
>>>> side project of BioCocoa, because this is usable-right-now
>>>> tested code, just like BioCocoa 1.6 is. I would do the following
>>>> structure in the repository, something close to the usual
>>>> "recommanded" layout:
>>>>
>>>> BioCoao
>>>> ...Trunk
>>>> ......
>>>> ......[Checkout of the latest CVS repository]
>>>> ......
>>>> ...Tags
>>>> ......BioCocoa 1.6 <-- BCReader from Peter
>>>> ......BioCocoa 1.7 <-- BCReader from Alex
>>>> ......Goodies
>>>> .........EntrezController 1.0 <--- From Alex
>>>> .........KDTextView 1.0 <-- From Koen
>>>> .........KDTextView 1.1 <-- From Alex
>>>> ...Branches
>>>> ......Goodies
>>>>
>>>>
>>>> The "Goodies" directory could be named something else, like
>>>> "Subprojects" or whatever you like, and might alternatively be
>>>> moved to the root (under BioCocoa), and have its own Trunk, Tags
>>>> and Branches.
>>>>
>>>> The "Branches" directory is empty right now, but might soon have
>>>> a "BioCocoa 1.x" branch if we want to fix bugs / add features on
>>>> the 1.7 version, and/or have a "Goodies/KDTextView 1.x" branch
>>>> for the same reasons. Of course, the code for these should be
>>>> merged in the BioCocoa Trunk as soon as possible too, and we
>>>> probably don't want to generate too much code on the 1.x versions.
>>>>
>>>> Let's take advantage of super-easy management of Tags and
>>>> Branches with Subversion... Just my 2 cents!
>>>>
>>>> charles
>>>>
>>>>
>>>> On Mar 6, 2006, at 4:33 AM, Peter Schols wrote:
>>>>
>>>>> Hi Alex and other listers,
>>>>>
>>>>> This BCAppkitTest works great and it will be a great addition
>>>>> to BioCocoa!
>>>>> Over the weekend, I have worked with the - very helpful -
>>>>> people at Bioinformatics.org to solve my login problems (it
>>>>> turned out to be a proxy issue that was caused by a bug on
>>>>> their end, they have been able to fix it).
>>>>> As a result, I am totally ready to start the subversion
>>>>> repository and do the initial import.
>>>>>
>>>>> The main question I have now is: how should we organise the
>>>>> repository and the BioCocoa website? There are several scenarios:
>>>>>
>>>>> 1. Checkout the latest version of the BioCocoa framework from
>>>>> CVS and use that as the initial import for SVN. Make the
>>>>> BCAppkitTest available as a download on our website (both
>>>>> source and compiled app) but wait to put it in the repository
>>>>> until it's adapted to use the classes in our own framework.
>>>>>
>>>>> 2. Checkout the latest version of the BioCocoa framework from
>>>>> CVS and use that as the initial import for SVN. Make a second
>>>>> repository (I think this is possible @ bioinformatics.org) and
>>>>> put BCAppkitTest in there.
>>>>>
>>>>> 3. Checkout the latest version of the BioCocoa framework from
>>>>> CVS, add the BCAppkitTest somewhere in the hierarchy of that
>>>>> same BioCocoa folder and check this hybrid framework in to one
>>>>> repository.
>>>>>
>>>>>
>>>>> I think I'd prefer solution number 1 (or 2) because
>>>>> - it seems a bit weird to have part of a framework that does
>>>>> not use the base classes available in the rest of the framework
>>>>> - it might confuse users of the framework
>>>>> - we should aim to integrate BCAppkitTest into BioCocoa asap,
>>>>> this won't be a huge undertaking
>>>>>
>>>>> Please let me know your preference and I would be glad to
>>>>> create the Subversion repository and send instructions on using
>>>>> it. I'd also be glad to update the website and make the
>>>>> BCAppkitTest available.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>> On 06 Mar 2006, at 11:08, Alexander Griekspoor wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> With EnzymeX3 now in beta testing phase it's time to share the
>>>>>> wealth...
>>>>>> I've thrown together a very simple demo app showing the three
>>>>>> goodies I would like to donate back to the BioCocoa project:
>>>>>> - BCReader, the standalone BCReader classes for sequence file
>>>>>> IO (original version Peter Schols)
>>>>>> - EntrezController, a controller plus view for browsing and
>>>>>> fetching NCBI's Entrez Database
>>>>>> - KDTextView+, a custom NSTextView for displaying biological
>>>>>> sequences (original version Koen van der Drift)
>>>>>>
>>>>>> Download and enjoy at: http://www.mekentosj.com/biococoa/
>>>>>> BCAppkit_Test.dmg
>>>>>> Of course all feedback and bug reports are welcome (or not
>>>>>> depending on how you interpret this sentence ;-)
>>>>>>
>>>>>> Also, coming back to Koen's remark. There are a few things I/
>>>>>> we could do.
>>>>>> First, it would be nice if it had these views mentioned as
>>>>>> available on the website and the code given a place on the svn
>>>>>> server.
>>>>>> Second, we could perhaps post a small announcement (few lines)
>>>>>> on cocoa-dev to notify other cocoa developers, also letting
>>>>>> them know about BioCocoa again.
>>>>>> Finally, we could compose a little message to MacResearch
>>>>>> describing the BioCocoa project and also the availability of
>>>>>> this code.
>>>>>> Alternatively, I can inform them about it when we release the
>>>>>> EnzymeX final version. I believe Tom spoke a few times with
>>>>>> the guys behind MacResearch, so we could inform them
>>>>>> directly.. Let me know what you guys think.
>>>>>> Cheers,
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> *********************************************************
>>>>>> ** Alexander Griekspoor **
>>>>>> *********************************************************
>>>>>> The Netherlands Cancer Institute
>>>>>> Department of Tumorbiology (H4)
>>>>>> Plesmanlaan 121, 1066 CX, Amsterdam
>>>>>> Tel: + 31 20 - 512 2023
>>>>>> Fax: + 31 20 - 512 2029
>>>>>> AIM: mekentosj at mac.com
>>>>>> E-mail: a.griekspoor at nki.nl
>>>>>> Web: http://www.mekentosj.com
>>>>>>
>>>>>> 4Peaks - For Peaks, Four Peaks.
>>>>>> 2004 Winner of the Apple Design Awards
>>>>>> Best Mac OS X Student Product
>>>>>> http://www.mekentosj.com/4peaks
>>>>>>
>>>>>> *********************************************************
>>>>>>
>>>>>> _______________________________________________
>>>>>> Biococoa-dev mailing list
>>>>>> Biococoa-dev at bioinformatics.org
>>>>>> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>>>>>>
>>>>>
>>>>>
>>>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>>
>>
>> --
>> 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
>>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
--
Xgrid-at-Stanford
Help science move fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford
Charles Parnot
charles.parnot at gmail.com
More information about the Biococoa-dev
mailing list