[kepler-dev] draft conversion of ptII tree from svn to cvs and svn nits

[Edward A. Lee]

It's always tempting to spend time switching software infrastructure to
the "next new thing," but I want to point out that every hour we spend
converting to SVN is one hour less that we spend improving Ptolemy II and
Kepler.  I have not yet heard a compelling argument for this conversion.
I would really rather spend the time improving customizability of the UI
(to have custom front panels for workflows), leveraging Netbeans and/or
Eclipse, improving our testing infrastructure, etc.

On these:

At 12:56 AM 6/4/2008, ian.brown at hsbcib.com wrote:

>Christopher, 
>        the benefits I see from SVN are different than what you highlight. In particular they are: 
>
>1. Atomic commits. The directory itself is versioned and so when you commit number of files to implement an issue they naturally stay together. Also, if a network problem happens you don't get into a situation where only some of the files are committed. 

Isn't this easily accomplished by using a date?


>2. Better binary file handling. Binary diffs are stored and transmitted making updates faster and repository storage smaller. 

The real problem with CVS and binaries, IMHO, is that users get
it wrong and commit them as ASCII files, and they are corrupted
in the repository.  Does SVN prevent this?  It's hard to see how
it could...  Eclipse helps a great deal because it makes smart
guesses, and usually gets it right...


>3. Updates / commits are faster because diffs are sent both directions on the network whilst CVS tends to only send diffs from server -> client and sends entire files in the other direction. 

I guess on performance issues, the tradeoff is: Do we save more time
than we spent on the conversion to SVN?  This does not seem clear to me.


>I've not seen the disk hog stuff before. I assume this is the repository size on the server and not the client. You expect the client size to be twice that of CVS because SVN makes a backup of each file so that it can do local diff and rollback without needing to contact the server over the network. On the server, are you using the file storage configuration? 

The local size bloat seems problematic to me...
Particularly since I use Eclipse, which already provides this
rollback... So presumably I will pay the price twice.
I'm chronically out of disk space on my laptop these days
(yes, I should upgrade my laptop, but that requires two weeks
of time that will not be spent improving Ptolemy II... :-)

Edward


------------ 
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html