[kepler-dev] draft conversion of ptII tree from svn to cvs and svn nits
Matthew Jones
jones at nceas.ucsb.edu
Wed Jun 4 09:06:23 PDT 2008
I agree with Ian about the advantages he lists. Here's a few more notes
from my perspective.
I have not encountered the disk size issues, and instead have seen the
opposite -- modules we have converted using cvs2svn are generally about
50% smaller on disk in SVN compared to CVS. Branches and tags in SVN
are much smaller than their counterparts in CVS, as they basically use
symbolic links and only store differences to the branched file, compared
with CVS that frequently makes full copies upon branching.
I set up SVN on our machines to use apache as its web front end, as we
already have apache running there, and it is more mature than the
built-in web server. The apache server is among the most mature,
stable, and secure network access systems available, and has excellent
support for SSL and integration with our backend systems like LDAP. I'd
far prefer to install apache and provide http access to the source code
system than to maintain our current CVS-over-SSH tunnel, which requires
shell access for each user. I think using apache for access makes the
system much more secure than using shell accounts for unknown users, or
even worse, using pserver for CVS anonymous access.
On the client side, setting up CVS over SSH has been a difficult process
for many people (especially the SSH protocol 1 to SSH protocol 2
transition, which wasn't supported in many graphical CVS clients), and I
have seen that SVN offers us a much simpler path for users to get
connected. Plus, most firewalls allow port 80 and 443 to pass freely,
while we've run into a number of problems with people getting blocked on
port 22 using CVS over SSH.
Another advantage is the improved access control that is possible via
both the Apache access module and the use of the SVN authz file. This
has allowed us to create private SVN repositories and subdirectories
with fine-grained access directives, and have precise control of
anonymous access to modules and directories. None of this is possible
with CVS -- the best you can do there is use a single unix user and
group to control access, which hasn't worked very well for us.
Moving and renaming files and directories is possible in SVN and a
welcome feature. We have suffered for years with artifacts associated
with CVS not allowing repository reorganization. So I think the 'move'
capability is a major improvement over CVS.
I think we will be able to make excellent use of the svnsync program,
especially given that we have this split system between ptolemy and
kepler. I suspect that we will appreciate svnsync's ability to keep a
local copy of the ptolemy code completely synchronized. We also can
sync to a service like Google Code if we want to provide broader access
to the code while maintaining our own servers.
From a day-to-day usage perspective, I've found the two systems are
largely the same. Using checkout, update, and commit are the same
operations in both systems, and svn's version of status and log are much
nicer. So for most people they will find the system familiar but with
some better features. The eclipse plugin works the same way as the CVS
plugin does, so there will be no noticeable client side differences for
eclipse users that I can see (other than new features).
Regards,
Matt
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.
>
> 2. Better binary file handling. Binary diffs are stored and transmitted
> making updates faster and repository storage smaller.
>
> 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'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?
>
> Ian
>
>
>
> *"Christopher Brooks" <cxh at eecs.berkeley.edu>*
> Sent by: kepler-dev-bounces at ecoinformatics.org
>
> 04/06/2008 04:14
> *Mail Size: 6485*
>
>
> To
> kepler-dev at ecoinformatics.org
> cc
>
> Subject
> [kepler-dev] draft conversion of ptII tree from svn to cvs and svn
> nits
> Entity
> Investment Banking Europe - IBEU
>
>
>
>
>
>
>
>
> I have some notes about svn at
> http://chess.eecs.berkeley.edu/ptolemy/wiki/Ptolemy/Subversion
>
> The gist of this is reported below:
>
> I did a first cut of a conversion from cvs to svn for the ptII tree.
>
> To try it from the command line:
> svn co svn+ssh://source.eecs.berkeley.edu/home/svn_chess/ptII/trunk
> mv trunk ptII
> cd ptII
> ./configure
>
> Note that this is just a test copy, this is not a live copy, I'll be
> deleting the svn tree and creating it again from cvs when I'm ready to
> move over. So, _don't_check_in_changes_ to the ptII svn repository
> and expect to see them last.
>
> I'll be working on the Eclipse setup and on a real set of instructions.
>
> I found a few interesting nits about svn:
>
> * Is svn that much better than cvs? http://subversion.tigris.org
> says "Subversion is meant to be a better CVS, so it has most of
> CVS's features". Typical arguments used for svn over cvs:
> o Merging in svn is better than in cvs. How many people
> actually use branches?
> o It is easier to move files in svn than in cvs. This has
> some merit, but is it worth the effort?
> * Building the client requires way too many other packages. How
> can svn possibly stay secure if it depends on so many packages
> * Subversion can optionally use Apache for access. Enabling a web
> server on a machine that does not already have one makes the
> machine less secure.
> * There is no decent svn Unix style man page. This is deliberate,
> see Bug 1508. This is not good. I want to know exactly what
> commands will work with a specific installation of SVN, not what
> the latest documentation for the latest version is.
> * svn is a disk hog.
> o A gzipped tar file of the Ptolemy II cvs tree is 372.9 MB.
> o A gzipped tar file of the same tree after running the
> conversion from cvs to svn is 570MB.
>
>
> _Christopher
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
>
> ************************************************************
> HSBC Bank plc may be solicited in the course of its placement efforts
> for a new issue, by investment clients of the firm for whom the Bank as
> a firm already provides other services. It may equally decide to
> allocate to its own proprietary book or with an associate of HSBC Group.
> This represents a potential conflict of interest. HSBC Bank plc has
> internal arrangements designed to ensure that the firm would give
> unbiased and full advice to the corporate finance client about the
> valuation and pricing of the offering as well as internal systems,
> controls and procedures to identify and manage conflicts of interest.
>
> HSBC Bank plc
> Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
> Registered in England - Number 14259
> Authorised and regulated by the Financial Services Authority.
> ************************************************************
>
> ------------------------------------------------------------------------
>
> * SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued
> by a member of the HSBC Group "HSBC" for the information of the
> addressee only and should not be reproduced and/or distributed to any
> other person. Each page attached hereto must be read in conjunction with
> any disclaimer which forms part of it. Unless otherwise stated, this
> transmission is neither an offer nor the solicitation of an offer to
> sell or purchase any investment. Its contents are based on information
> obtained from sources believed to be reliable but HSBC makes no
> representation and accepts no responsibility or liability as to its
> completeness or accuracy. *
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the Kepler-dev
mailing list