[kepler-dev] [Ptolemy] Conversion of Ptolemy II Tree to SVN this week

Christopher Brooks cxh at eecs.berkeley.edu
Wed Jun 11 08:07:05 PDT 2008


I'm bringing the Ptolemy II cvs repository down and starting
the conversion to svn.

I've put up my notes about the conversion as
http://chess.eecs.berkeley.edu/ptexternal/wiki/Main/Subversion

Here's my manifesto.

After a few years, it has come to my attention that everything old is
new again, that is, tools are created that have only incremental
improvements over the old tools and the new tools are often not as
good as the old tools.  Ant is the canonical case.  The Ant website
said it was created by someone who did not understand the make syntax.
The first few releases of Ant did not have dependency analysis.  Over
time, Ant has become more useful and is now a defacto standard for
developing new Java projects.  However, the Ant syntax sucks, people
still write XML files by hand.  In this case, the Ant emperor has no
clothes, or at least clothes similar to make.

To quote GW Bush:

"There's an old saying in Tennessee  I know it's in Texas, probably in
Tennessee  that says, fool me once, shame on  shame on you. Fool me
you can't get fooled again."

This brings us to svn and getting fooled again.  I feel that svn has
one feature we need: it can operate over a http connection - if you
are willing to decrease security by installing a web server and add
complexity by managing accounts.  This does not fit our current
infrastructure, but could.  Allowing the paying sponsors of CHESS and
Ptolemy to easily access our code base is a good business reason to
move forward.  CVS cannot easily run over port 80, I tried and
stateful firewalls see that the packets are not http packets and drop
them.

A second reason is that running svnsync could help make it easier
for Kepler to mirror parts of the Ptolemy II tree.

A third reason is that moving files in svn should preserve the
change log.

There are other reasons, but I think they are smoke and mirrors.

There are plenty of downsides:  svn is much more complex, much less
secure and there are concerns about the Eclipse interface.

If you look at this from Edward's point of view, he is trading
something that works (cvs) for something that may have problems (svn).
I understand why he would not want to become less productive.

However, in really thinking about how people work, I realize that most
developers pick up tools and then rarely drop them.  I, for one have
been using emacs for 20 years.  This might not be good.  I also use
Eclipse, but not as much as I could.  I was resistant to the
conversion from SCCS to CVS, but after John Reekie started using
CVS, I switched and after complaining, saw that CVS was good.

Working in education, I feel that we need to expose students to
current tools they will face in their future positions.  SVN is tool
that is out there and that students will either use or consider using.
All along, I've said that if I was starting over, I would choose ant,
maven, svn and Junit.  I find it disturbing that Ed Willink, someone
whose opinion I greatly value, was arguing that he was considering cvs
for a new project.  I find it disturbing because all along I thought
that svn was better than cvs and now I'm starting to think that svn is
just different and agreeing with Ed Willink and Edward.  Svn has a
couple of features we want and a bunch of downsides.

However, I feel that as an educational institution, we also have the
luxury of trying experiments.

So, I'm moving ptII to svn and if it is really bad, I'll move us back
to cvs.  However, I'm going to work hard at svn. Even though it might
not be the best use of my time for my efforts, I feel that it will
help the community at large. 

I really appreciate everyone's feedback and the discussion about svn
and ant.  I also hope I illustrated the point that there is a tension
between upgrading to the latest and greatest vs stability.  I'm
surprised at some of the downsides of svn, and feel that the svn
developers attempted to fix parts of cvs but ended up fixing a few
things at a rather great cost.

_Christopher

Christopher Brooks (cxh at eecs berkeley edu) University of California
Chess Executive Director                      US Mail: 337 Cory Hall #1774
Programmer/Analyst Chess/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (office: 400A Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480  






  



--------

    > Subversive is an Eclipse incubation project, so it may in due course be
    > part of Eclipse. (It's almost at the bottom of the Downloads by Project
    > page.)
    
    Subversive will never be part of the Eclipse core. Eclipse is really
    moving the other direction, they even removed CVS from the core. There
    will likely be future efforts coming out of the Eclipse Packaging
    Project (EPP) where you can build or obtain Eclipse packages that
    include Subversion and/or CVS. Subclipse made a conscious decision to
    not make the Subclipse project part of Eclipse.org.
    
    > Subversive is better than Subclipse in that it automatically performs the
    > folder incoming updates following outgoing commits.
    
    I actually prefer how Subclipse handles this. Typically after a
    check-in I want to know what revision that was so I can reference it
    in the Trac ticket I'm closing , this makes it easy.
    
    On Tue, Jun 10, 2008 at 9:00 AM, Willink, Ed <Ed.Willink at thalesgroup.com> w
   rote:
    > Hi All
    >
    > I started using Subversion a few months ago and only this morning was
    > arguing strongly
    > that a new project should start on CVS and not SVN.
    >
    > Subversive is an Eclipse incubation project, so it may in due course be
    > part of Eclipse. (It's almost at the bottom of the Downloads by Project
    > page.)
    >
    > Subversive is better than Subclipse in that it automatically performs the
    > folder incoming updates following outgoing commits.
    >
    > I managed to install subversive on 3.4M7 following the install the previo
   us
    > version
    > then the current version method. I haven't succeeded in getting Subversiv
   e
    > working
    > on 3.4RC1. Maybe I'm just stupid. Maybe the installation process is evolv
   ing
    > out of sync with the documentation.
    >
    > I found both Subversive and Subclipse painful; I had to perform significa
   nt
    > repairs externally using TortoiseSVN. I even managed to get Subversive to
    > delete a 10MB directory tree by mistake!
    >
    > Both Subversive and Subclipse are very dangerous for CVS users. In CVS,
    > folders
    > do not have significant state so you can do what you like when you like. 
   In
    > SVN
    > you MUST commit folder state immediately after committing file state. For
    > instance
    > if you add something to svn:ignore, you must commit the folder, otherwise
    > you
    > risk having an outgoing conflict between svn:ignore outgoing and child
    > folder
    > state incoming. Do not attempt to fix such a conflict with either of
    > Subclipse
    > or Subversive; you just dig a deeper hole. Use TortoiseSVN to get back to
    > all green arrows.
    >
    > Unfortunately neither subclipse nor subversion have GUI state for folder
    > state
    > comparison so you get no clue as to why folders are in a mess. The GUI is
    > generally inadequate in distinguishing between folder as content and fold
   er
    > as container of children.
    >
    > Enjoy.
    >
    >     Regards
    >
    >         Ed Willink
    >
    >
    > ________________________________
    > From: ptolemy-admin at chess.eecs.berkeley.edu
    > [mailto:ptolemy-admin at chess.eecs.berkeley.edu] On Behalf Of Jia Zou
    > Sent: 09 June 2008 20:46
    > To: Jackie Man-Kit Leung
    > Cc: kepler-dev at ecoinformatics.org; ptdevel at chess.eecs.berkeley.edu;
    > Christopher Brooks
    > Subject: Re: [Ptolemy] Conversion of Ptolemy II Tree to SVN this week
    >
    > Hi Christopher, Jackie, and others,
    > From what I heard here at IBM, where Subclipse is widely used, there are
    > many subtle functionalities Subclipse does not implement correctly, and t
   hus
    > many researchers here use command line to run subversion instead of
    > Subclipse.
    > So could you post a tutorial on how we can run subversion both on eclipse
    > and command line?
    > I didn't hear anything about Subversive.
    >
    > Jia
    >
    > On Mon, Jun 9, 2008 at 3:37 PM, Jackie Man-Kit Leung <jleung at berkeley.edu
   >
    > wrote:
    >>
    >> Is the conversion "backward compatible"? Would the old cvs clients still
    >> work? or do we need to upgrade to svn client..... If so, there are two
    >> eclipse svn client plugin: Subclipse and Subversive. Which one do we
    >> recommend? The two seem to be very similar, in terms of licensing,
    >> maturity.....Does anyone know which is better, functionality-wise?
    >>
    >> ~mankit
    >>
    >>
    >>
    >> ----- Original Message ----- From: "Christopher Brooks"
    >> <cxh at eecs.berkeley.edu>
    >> To: <kepler-dev at ecoinformatics.org>; <ptdevel at chess.eecs.berkeley.edu>
    >> Sent: Monday, June 09, 2008 9:31 AM
    >> Subject: [Ptolemy] Conversion of Ptolemy II Tree to SVN this week
    >>
    >>
    >>> I'm thinking about converting the Ptolemy II cvs repository to
    >>> subversion this week.
    >>>
    >>> To do this, what I would do is:
    >>> 1) Update the Eclipse installation instructions
    >>> 2) Disable the ptII cvs repository
    >>> 3) Convert the ptII cvs repository to svn, which would take a few
    >>> hours
    >>>
    >>> I'm thinking of doing this on Wednesday.
    >>>
    >>> Any comments, questions or concerns?
    >>>
    >>> _Christopher
    >>> _______________________________________________
    >>> Ptolemy maillist  -  Ptolemy at chess.eecs.berkeley.edu
    >>> http://chess.eecs.berkeley.edu/ptolemy/listinfo/ptolemy
    >>>
    >>
    >> _______________________________________________
    >> Ptolemy maillist  -  Ptolemy at chess.eecs.berkeley.edu
    >> http://chess.eecs.berkeley.edu/ptolemy/listinfo/ptolemy
    >
    > *************************************************************************
   ******
    >
    > Please consider the environment before printing this email.
    >
    > *************************************************************************
   ******
    >
    > This email and any files transmitted with it are intended solely for the 
   use
    > of
    >
    > the individual or entity to whom they are addressed and may not be divulg
   ed
    > to
    >
    > any third party without the express permission of the originator. Any vie
   ws
    >
    > expressed in this message are those of the individual sender, except wher
   e
    > the
    >
    > sender specifically states them to be the views of Thales Research &
    > Technology
    >
    > (UK) Limited.
    >
    > *************************************************************************
   ******
    >
    >
--------


More information about the Kepler-dev mailing list