[kepler-dev] draft conversion of ptII tree from svn to cvs and svn nits
Christopher Brooks
cxh at eecs.berkeley.edu
Wed Jun 18 20:50:49 PDT 2008
Hi Tristan,
Thanks for the info on git!
A little more data.
- cvs2svn requires local access to the cvs repository, it will not
work remotely. This has caused problems with people who have
sourceforge cvs repositories and want to convert them to svn.
I think those sourceforge eventually addressed those issues.
The cvs2svn faq is vague about why the tool needs local access, I
think it was just easier if cvs2svn has local access than trying
to do it remotely.
The fact that git can clone a svn tree remotely is a credit to
both git and svn.
As a reminder, converting from cvs2svn took about 2 hours for just
under 50k of changes.
The 12 hours for a checkout is quite a bit, but it using an internet
connection between Australia and California, so who knows.
I have no particular problem with you leaving the git snapshot of the
ptII tree up. It could cause problems if someone thinks it is a live
snapshot, but most git users have the sophistication to avoid this.
- Another drawback with svn is that the modtimes of the files are not
preserved. When I do a cvs checkout, the modtimes of the files
are preserved. This makes it much easier to see what has
recently changed.
Here's the svn tree:
bash-3.00$ ls -ltr ~/ptII/ptolemy/kernel/util/*Exception.java
-rw-r--r-- 1 cxh labstaff 18596 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/KernelException.java
-rw-r--r-- 1 cxh labstaff 9137 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/KernelRuntimeException.java
-rw-r--r-- 1 cxh labstaff 5858 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/InvalidStateException.java
-rw-r--r-- 1 cxh labstaff 3646 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/InternalErrorException.java
-rw-r--r-- 1 cxh labstaff 5121 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/IllegalActionException.java
-rw-r--r-- 1 cxh labstaff 4937 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/NameDuplicationException.java
-rw-r--r-- 1 cxh labstaff 2660 Jun 12 13:10 /home/eecs/cxh/ptII/ptolemy/kernel/util/NoSuchItemException.java
Here's the cvs tree:
bash-3.00$ ls -ltr ~/src/ptII.cvs/ptolemy/kernel/util/*Exception.java
-rw-r--r-- 1 cxh labstaff 5125 Jul 8 2005 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/IllegalActionException.java
-rw-r--r-- 1 cxh labstaff 3650 Jul 8 2005 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/InternalErrorException.java
-rw-r--r-- 1 cxh labstaff 4941 Jul 8 2005 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/NameDuplicationException.java
-rw-r--r-- 1 cxh labstaff 2664 Jul 8 2005 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/NoSuchItemException.java
-rw-r--r-- 1 cxh labstaff 18600 Dec 6 2007 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/KernelException.java
-rw-r--r-- 1 cxh labstaff 9141 Dec 6 2007 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/KernelRuntimeException.java
-rw-r--r-- 1 cxh labstaff 5862 Jun 6 08:13 /home/eecs/cxh/src/ptII.cvs/ptolemy/kernel/util/InvalidStateException.java
bash-3.00$
Why doesn't svn preserve mod times?
- I started to look at why the time of the svn2cl script takes so
long and I think it is because it is using xsltproc. This says very
poor things the xsltproc tool, but optimization may help here.
- Remaining tasks
- Set up svn commit email
- ChangeLog Generation
- Enable svn update on the CHESS website
- Set up a web server on source (much longer term)
I'm seriously considering writing a tech report called "Subversion
considered harmful". I think that it would have been better to fix a
few problems in cvs instead of creating new problems with svn.
The upgrade experience has been an eye opener on how not to evolve
software, hopefully I've learned something. I do feel that svn has
one thing that the Ptolemy project really requires, and that is
easy access by our sponsors via firewalls. Perhaps CVS could have
been enhanced to handle this?
In other news, I upgraded emacs so that it could handle svn files and
found that the mh-e package I use to read email had been "upgraded" so
that the command bindings had changed. I'm not sure why the change
was made but, I've been using the same key-stroke bindings for 18
years. The Mh-e developers should have either not made the changes or
else provided a backward compatibility mode. Sigh.
Fortunately, we were able to fall back to an older version of mh-e.
I'll leave the discussion about the vagaries of mail readers for
another thread.
Another great lesson learned.
It is too bad the git clients did not meet my needs. Git would probably
have a different set of problems though.
Again, thanks for looking into this, I'm glad we considered git.
_Christopher
--------
Just thought I'd give a quick review of my git experience with git-svn and
the ptolemy svn (read: i'm not trying to say we should move everything to
git, just posting my experience for those who're interested).
git svn clone takes a long time to run. this is because it downloaded every
revision to the local disk. I started it at about 3pm, and by 6 it had done
just over 10000 revisions. So by that i assume it took about 12 hours to
complete the git equivalent of a checkout.
This checkout, which isn't compressed, takes up 668mb.
Pushing the repository to jcu's central git repository (the equivalent of a
svn/cvs server) which stores everything differently from working copies too
k
up 275mb (compressed with tar.gz to 268mb).
cloning the central git repository from the central server took a bit more
time than an svn checkout, but not by much. The resulting working copy
(which is compressed) is 453mb . my svn checkout is 479mb. This surprised
me, as I thought git would be much larger due to it having every revision
available from the local machine, however, I suspect that over time it may
explode to be closer to the uncompressed git-svn clone size.
One issue tho is I don't think git has anything like svn:properties built i
n
(except svn:ignore). modifying the $Id: etc$ type variables in source files
could probably be achieved with post-commit hooks, but I've not played with
them yet, so i've no idea how hard they would be to set up.
I've removed the git mirror of ptII from jcu's central git repository for
now, but if anyone is interested in having a look at how it looks in the we
b
ui or even cloning it out send me a bell. I don't want to leave it up there
unless Christopher/Edward are OK with that, and even so it definitely
wouldn't be kept up to date, i've just done this for curiosity's sake.
Cheers
-Tristan
On Wed, Jun 4, 2008 at 1:14 PM, Christopher Brooks <cxh at eecs.berkeley.edu>
wrote:
> 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
>
--
Tristan King
Research Officer,
eResearch Centre
James Cook University, Townsville Qld 4811
Australia
Phone: +61747816902
E-mail: tristan.king at jcu.edu.au www: http://eresearch.jcu.edu.au
------=_Part_4509_17092260.1213844542926
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Just thought I'd give a quick review of my git experience with git-svn
and the ptolemy svn (read: i'm not trying to say we should move everythi
ng to git, just posting my experience for those who're interested).<div>
<br></div><div>git svn clone takes a long time to run. this is because it d
ownloaded every revision to the local disk. I started it at about 3pm, and b
y 6 it had done just over 10000 revisions. So by that i assume it took about
12 hours to complete the git equivalent of a checkout.</div>
<div><br></div><div>This checkout, which isn't compressed, takes up 668
mb.</div><div><br></div><div>Pushing the repository to jcu's central git
repository (the equivalent of a svn/cvs server) which stores everything dif
ferently from working copies took up 275mb (compressed with tar.gz to 268mb)
.</div>
<div><br></div><div>cloning the central git repository from the central ser
ver took a bit more time than an svn checkout, but not by much. The resultin
g working copy (which is compressed) is 453mb . my svn checkout is 479mb. Th
is surprised me, as I thought git would be much larger due to it having ever
y revision available from the local machine, however, I suspect that over ti
me it may explode to be closer to the uncompressed git-svn clone size.</div>
<div><br></div><div>One issue tho is I don't think git has anything lik
e svn:properties built in (except svn:ignore). modifying the $Id: etc$ type
variables in source files could probably be achieved with post-commit hooks,
but I've not played with them yet, so i've no idea how hard they wo
uld be to set up.</div>
<div><br></div><div>I've removed the git mirror of ptII from jcu's
central git repository for now, but if anyone is interested in having a look
at how it looks in the web ui or even cloning it out send me a bell. I don&
#39;t want to leave it up there unless Christopher/Edward are OK with that,
and even so it definitely wouldn't be kept up to date, i've just don
e this for curiosity's sake.</div>
<div><br></div><div>Cheers</div><div>-Tristan</div><div><br><div class="gma
il_quote">On Wed, Jun 4, 2008 at 1:14 PM, Christopher Brooks <<a href="ma
ilto:cxh at eecs.berkeley.edu">cxh at eecs.berkeley.edu</a>> wrote:<br><blockqu
ote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;
padding-left:1ex;">
I have some notes about svn at<br>
<a href="http://chess.eecs.berkeley.edu/ptolemy/wiki/Ptolemy/Subversion" ta
rget="_blank">http://chess.eecs.berkeley.edu/ptolemy/wiki/Ptolemy/Subversion
</a><br>
<br>
The gist of this is reported below:<br>
<br>
I did a first cut of a conversion from cvs to svn for the ptII tree.<br>
<br>
To try it from the command line:<br>
svn co svn+ssh://<a href="http://source.eecs.berkeley.edu/home/svn_c
hess/ptII/trunk" target="_blank">source.eecs.berkeley.edu/home/svn_chess/ptI
I/trunk</a><br>
mv trunk ptII<br>
cd ptII<br>
./configure<br>
<br>
Note that this is just a test copy, this is not a live copy, I'll be<br
>
deleting the svn tree and creating it again from cvs when I'm ready to<
br>
move over. So, _don't_check_in_changes_ to the ptII svn repositor
y<br>
and expect to see them last.<br>
<br>
I'll be working on the Eclipse setup and on a real set of instructions.
<br>
<br>
I found a few interesting nits about svn:<br>
<br>
* Is svn that much better than cvs? <a href="http://subversio
n.tigris.org" target="_blank">http://subversion.tigris.org</a><br>
says "Subversion is meant to be a better CVS, so
it has most of<br>
CVS's features". Typical arguments used for s
vn over cvs:<br>
o Merging in svn is better than in cvs.
How many people<br>
actually use branches?<br>
o It is easier to move files in svn than
in cvs. This has<br>
some merit, but is it worth the e
ffort?<br>
* Building the client requires way too many other packages. H
ow<br>
can svn possibly stay secure if it depends on so many
packages<br>
* Subversion can optionally use Apache for access. Enabling a
web<br>
server on a machine that does not already have one mak
es the<br>
machine less secure.<br>
* There is no decent svn Unix style man page. This is deliber
ate,<br>
see Bug 1508. This is not good. I want to know exactly
what<br>
commands will work with a specific installation of SVN
, not what<br>
the latest documentation for the latest version is.<br
>
* svn is a disk hog.<br>
o A gzipped tar file of the Ptolemy II c
vs tree is 372.9 MB.<br>
o A gzipped tar file of the same tree af
ter running the<br>
conversion from cvs to svn is 570
MB.<br>
<br>
<br>
_Christopher<br>
_______________________________________________<br>
Kepler-dev mailing list<br>
<a href="mailto:Kepler-dev at ecoinformatics.org">Kepler-dev at ecoinformatics.or
g</a><br>
<a href="http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepl
er-dev" target="_blank">http://mercury.nceas.ucsb.edu/ecoinformatics/mailman
/listinfo/kepler-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Tristan King<br>Research
Officer,<br>eResearch Centre<br>James Cook University, Townsville Qld 4811<b
r>Australia<br><br>Phone: +61747816902<br>E-mail: <a href="mailto:tristan.ki
ng at jcu.edu.au">tristan.king at jcu.edu.au</a> www: <a href="http://eresearch.jc
u.edu.au">http://eresearch.jcu.edu.au</a>
</div>
------=_Part_4509_17092260.1213844542926--
--------
More information about the Kepler-dev
mailing list