[SciPy-dev] Re: scipy repository structure

[Travis N. Vaught]

CC'ing the dev list (please read below for context):

So...

It seems like we should first put things into:

www.scipy.org/svn/scipy/trunk/src/lib/
  scipy
  scipy_core

(allowing one to do this:  svn co https://svn.scipy.org/svn/scipy/trunk/
...and get what's needed for a build)

Next, get a release out of SciPy 0.3.3 using the existing relative 
locations of scipy, scipy_core, et al.

Then, work toward the grand unification of scipy and Numeric3 (which is 
actually scipy_base).  Constructing a world which will support a binary 
build of a stand_alone scipy_core (which will have scipy_base, f2py, 
scipy_distutils and scipy_test (or some approximation of those), and a 
binary build of the scipy "whole enchilada"--with proper consideration 
of the potential difficulties Pearu points out below.

Any input/objections?

Regards,

Travis

Joe Cooper wrote:

> pearu at cens.ioc.ee wrote:
>
>> For installing Numeric3 and scipy we can use two separate setup.py files
>> for each task but for checking out Numeric3 only (there might be users
>> who are not interested in scipy but Numeric3 alone) from the above tree
>> could be a problem.
>
>
> You can checkout any path within a subversion repository, so putting 
> everything into one repository is entirely sane, if everything is 
> closely related.  Some tools (trac, specifically) are designed around 
> a "one project, one repository" model, and so it does not deal with 
> many different packages in the same repository with anything 
> approaching sanity.  This has shaped our thinking on the enthought 
> tree to some degree (not a large degree, but a little bit).
>
> I expect we will want to begin using trac on scipy, as well, and so it 
> may be worth considering the limitations of trac.
>
>>> I'd also like to leave behind any deprecated libraries in the "old 
>>> CVS" rather than cluttering the new repository.
>>
>>
>>
>> I agree. I think only scipy, scipy_core, ipython(?) from the "old CVS"
>> need to be converted to svn. All other modules seem obsolute.
>
>
> ipython was the first to move to subversion.  Fernando has been 
> happily subverting for a couple of months.  I'll remove all of the 
> obsoletes.
>
>>> Please let me know if your thoughts.  I wanted to do any wholesale
>>> changes now rather than later, since we're setting up the repository
>>> anyway.  If we should do this post 3.3 let me know how to structure
>>> things to get us to that point.
>>
>>
>>
>> If we want to get 3.3 out as soon as possible then we should use the CVS
>> tree. It may take time to get Numeric3-scipy and restructured
>> svn-scipy to stable enough for the release.
>
>
> There is no need to restructure the Subversion repo before a release, 
> or we can branch before the reorg, or the person doing the reorg can 
> do it in a working copy.  Also, the subversion tree mimics the CVS 
> tree to a large degree, so there's probably no reason not to roll the 
> release from the SVN repo.  I'd be shocked if you can't check out the 
> trunk of scipy_core and scipy and have them act exactly the same as 
> the CVS versions.
>
> Just a reminder about some of the reasons for migrating to subversion:
>
> Branching is cheap and safe.
> Wholesale moves of directories and everything in them is cheap and safe.
> Everything (almost) that one can do to a subversion repository can be 
> done in a working copy, so everything (almost) is cheap and safe.
>
> I know everyone who has worked with CVS has some old "Egads, don't 
> move things around...we don't know what could happen!" notions that 
> are hard to overcome, because I still have those feelings too 
> sometimes.  So, it's worth mentioning that those fears are unjustified 
> with Subversion.


-- 
........................
Travis N. Vaught
CEO
Enthought, Inc.
http://www.enthought.com
........................