I've been lobbying the Tapestry committers to switch from CVS to SVN.
I'm getting a lot of push-back; as the enclosed mail indicates.
Further, I went from a reasonably stable environment with 0.9.30 to
completely unusable with 0.9.31 and had to downgrade. The JNI
intrerface no longer worked with either my local SVN or Apache's, and
the command line interface failed as well (it hung Eclipse, apparently
starting ssh.exe sub-processes in a loop forever. No idea what it was
doing ... may have been trying to collect QuickDiffs).
---------- Forwarded message ----------
From: Geoff Longman <glongman@gmail.com>
Date: Jul 10, 2005 8:02 AM
Subject: FYI: SVN Observations
To: Tapestry development <tapestry-dev@jakarta.apache.org>
I've been using Eclipse 3.1 final + svn 1.2.1 + subclipse 0.3.9 for
two weeks now and here is what I have found.
All these observations are from use in Eclipse so I guess the niggles
are all due to the implementation of subclipse (i hope). My use is not
an 'experiment'. I'm working in a team of 4 developers on a
substantial project. Syncing occurs more than 10 times a day.
1. SVN ignore files are not respected at all. ever. This is really
really annoying as each developer needs to create personalized
versions of a few spring xml files (and a hibernate properties file)
from templates. Since SVN ignore files are not respected the custom
files show up in the synchronize view ever time and have to be
manually removed from the view before committing. After a week and a
half I found a workaround. Right click on each file, choose
properties, and select the 'derived' flag. This setting is workspace
dependant and can't be shared via the repository so each developer has
to set the flag for each file in their workspace.
2. Quite often if another developer adds or removes a file in the
repository, that change *will not* appear in my workbench when I sync
up. This results in broken workbench builds. With some detective work
you realize that a change didn't show up and you can resync a few
times until the change appears. Even then only the package will appear
as changed. We are all working the same room so it has become an
informal policy to announce verbally such changes so everybody knows
their next sync will be problematic.
3. In the subclispe commit dialog you have to explicitly check a box
to add a new file. This is exactly the opposite to the cvs experience
where one would exclude a file you don't want to commit(add) by
removing it from the synch view *before* invoking the commit dialog.
Several times I've committed a set of files only to discover that the
new files didn't go in because I didn't check the box in the commit
dialog.
4. We tried to share Java formatter settings by using the project
specific preferences feature in Eclipse. That would allow us to avoid
sharing an export separately and then manually importing the settings.
Doing the puts a .somethingorother file in the root of the project.
This failed spectacularly. The user who shares the .somethingorother
file is ok but anybody else who tried to sync up found that jvm
crashes causing eclipse to go poof. The cause was JNI problems with
the svn native bindings.
There are other niggles that I have not experience personally so I
can't comment on them.
That said, the above problems man that the transition from cvs to svn
in Eclipse is not seamless. Hindsight is 20/20 but,knowing what I know
now, if I had joined this team before they moved from cvs to svn I
would have fought it vigorously.
Lastly, the other users in my group are not Eclipse veterans so I have
to repeatedly explain that it was not Eclipse that sucked. Rather it
is the subclipse plugin implementation that sucks.
Geoff
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Received on Mon Jul 11 04:37:03 2005