[kepler-dev] draft conversion of ptII tree from svn to cvs and svn nits
Christopher Brooks
cxh at eecs.berkeley.edu
Thu Jun 19 15:38:56 PDT 2008
Hi Ian,
Ian writes:
> Christopher,
> I don't know about the command line, but in TortoiseSVN, you can
> set the file dates to the last commit by telling it to do so in the
> settings. See the screenshot below.
> I guess you can do it from the command line too, but I rarely if ever use
> the command line.
>
>
>
> Ian
Thanks, that prompted me to look further and indeed there is a setting.
The setting is on a per machine or per user level.
The SVN Book, Chapter 7, Advanced Topics - covers setting
use-commit-times:
--start--
use-commit-times
Normally your working copy files have timestamps that reflect
the last time they were touched by any process, whether that be
your own editor or by some svn subcommand. This is generally
convenient for people developing software, because build
systems often look at timestamps as a way of deciding which
files need to be recompiled.
In other situations, however, it's sometimes nice for the
working copy files to have timestamps that reflect the last
time they were changed in the repository. The svn export
command always places these "last-commit timestamps" on trees
that it produces. By setting this config variable to yes, the
svn checkout, svn update, svn switch, and svn revert commands
will also set last-commit timestamps on files that they touch.
--end--
use-commit-times can be set in the Subversion config file. The
tricky part is finding that file. For me, under Cygwin, the file
was $HOME/.subversion/config. Other places to look are
c:/Documents and Settings/cxh/Application Data/Subversion/config
I uncommented use-commit-times:
### Set use-commit-times to make checkout/update/switch/revert
### put last-committed timestamps on every file touched.
use-commit-times = yes
The reason this is important is that ptII tree includes derived files
that are generated by Autoconf, JavaCC and Antlr. If the commit times
are not preserved, then the source file might have a mod time later
than the derived file which means that either the tool must be run or
else the build system must touch the derived file.
I don't think that we need to require users to set this, but if they
don't then Autoconf, JavaCC and Antlr will either need to be run or
make will need to be set up properly to run "touch". Fortunately,
I think the makefiles are set up properly.
I'm not sure how this would affect Maven or Ant if the tools are not
present though.
_Christopher
--------
"Christopher Brooks" <cxh at eecs.berkeley.edu>
Sent by: kepler-dev-bounces at ecoinformatics.org
19/06/2008 04:50
Mail Size: 20975
To
"Tristan King" <tristan.king at jcu.edu.au>
cc
kepler-dev at ecoinformatics.org
Subject
Re: [kepler-dev] draft conversion of ptII tree from svn to cvs and svn
nits
Entity
Investment Banking Europe - IBEU
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.ja
va
-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
More information about the Kepler-dev
mailing list