You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Geoff Longman <gl...@gmail.com> on 2005/07/10 14:02:37 UTC
FYI: SVN Observations
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
Re: FYI: SVN Observations
Posted by Colin Sampaleanu <co...@exis.com>.
My general experience has been that TortoiseSVN is quite good. We've had
a few issues even when using it, but generally they are annoyances (i.e.
there is a bit of breakage once in a while requiring a clean, but no big
surprises). The oinly other niggle with TortoiseSVN is that renames,
even through Tortoise, show up as a delete and a new checkin, which
defeats the whole purpose of subversion having real file tracking across
renames. Subclipse on the other hand seems completely unusable in real
use. All the stuff Geoff mentions plus a number of other things. I
wouldn't trust it for a second.. Admittedly, I haven't tried plugging in
the alternative JavaSVN java bindings instead of the default javahl. As
for the IDEA plugin, I don't have any personal experience using it (I
use eclipse). But one developer using IDEA with our svn repo somebody
using IDEA managed to completely break things for all other users on one
part of the source tree. Checking out would get some mysterious error,
and no amount of local work would fix things. I finally had to kill that
part of the source tree.
So I have a decent amount of respect for subversion, and a generally
positive experience with TortoiseSVN, but the IDE integration seems to
be far from usable. Given the need to do refactoring or other day to day
use in the IDE, I can't honestly reccomend SVN to people right now...
Alexandru Popescu wrote:
>Geoff thanks for publishing this detailed list of problems. Unfortunately I am not a Tapestry
>developer and when I was posting about this (having to agree that the level of detail was far from
>yours) nobody payed attention to it.
>I am discussing this subject for quite a while, but till now I get only assurance that the things
>will become better in the next few [put whatever term you like here].
>In the same line with your conclusion, even if SVN is a very good tool and there are some tools out
>there that makes working with it quite nice (I would quote TortoiseSVN - n.a.: i am not associated
>with), from the pov of Eclipse development there is no way I would migrate a project from cvs to
>svn. (moreover I have the same feedback from IntelliJ IDEA users).
>
>cheers,
>:alex |.::the_mindstorm::.|
>
>#: by Geoff Longman's words the mind was *winged* :#
>
>
>>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
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: FYI: SVN Observations
Posted by Alexandru Popescu <th...@evolva.ro>.
#: by Erik Hatcher's words the mind was *winged* :#
> On Jul 10, 2005, at 9:14 AM, Alexandru Popescu wrote:
>
>> Geoff thanks for publishing this detailed list of problems.
>> Unfortunately I am not a Tapestry
>> developer and when I was posting about this (having to agree that
>> the level of detail was far from
>> yours) nobody payed attention to it.
>> I am discussing this subject for quite a while, but till now I get
>> only assurance that the things
>> will become better in the next few [put whatever term you like here].
>> In the same line with your conclusion, even if SVN is a very good
>> tool and there are some tools out
>> there that makes working with it quite nice (I would quote
>> TortoiseSVN - n.a.: i am not associated
>> with), from the pov of Eclipse development there is no way I would
>> migrate a project from cvs to
>> svn. (moreover I have the same feedback from IntelliJ IDEA users).
>
> The latest EAP versions of IDEA have great support for Subversion.
> Much better than Subclipse it sounds like.
>
> While great IDE support is handy, I'm still a command line kinda guy
> when it comes to CVS and Subversion.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
You might be loosing a lot by not using the ide features ;-), but this is your decission :-).
:alex |.::the_mindstorm::.|
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: FYI: SVN Observations
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jul 10, 2005, at 10:16 AM, Ahmed Mohombe wrote:
>> The latest EAP versions of IDEA have great support for
>> Subversion. Much better than Subclipse it sounds like.
>>
> Said that there's no Tapestry plug-in for IDEA .
Don't get me wrong - I like Spindle a lot! Though I like IDEA more
than Eclipse and know how to work with Tapestry files by hand, so I
don't really miss it when I'm working in IDEA.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: FYI: SVN Observations
Posted by Ahmed Mohombe <am...@yahoo.com>.
> The latest EAP versions of IDEA have great support for Subversion.
> Much better than Subclipse it sounds like.
Said that there's no Tapestry plug-in for IDEA .
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: FYI: SVN Observations
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jul 10, 2005, at 9:14 AM, Alexandru Popescu wrote:
> Geoff thanks for publishing this detailed list of problems.
> Unfortunately I am not a Tapestry
> developer and when I was posting about this (having to agree that
> the level of detail was far from
> yours) nobody payed attention to it.
> I am discussing this subject for quite a while, but till now I get
> only assurance that the things
> will become better in the next few [put whatever term you like here].
> In the same line with your conclusion, even if SVN is a very good
> tool and there are some tools out
> there that makes working with it quite nice (I would quote
> TortoiseSVN - n.a.: i am not associated
> with), from the pov of Eclipse development there is no way I would
> migrate a project from cvs to
> svn. (moreover I have the same feedback from IntelliJ IDEA users).
The latest EAP versions of IDEA have great support for Subversion.
Much better than Subclipse it sounds like.
While great IDE support is handy, I'm still a command line kinda guy
when it comes to CVS and Subversion.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: FYI: SVN Observations
Posted by Alexandru Popescu <th...@evolva.ro>.
Geoff thanks for publishing this detailed list of problems. Unfortunately I am not a Tapestry
developer and when I was posting about this (having to agree that the level of detail was far from
yours) nobody payed attention to it.
I am discussing this subject for quite a while, but till now I get only assurance that the things
will become better in the next few [put whatever term you like here].
In the same line with your conclusion, even if SVN is a very good tool and there are some tools out
there that makes working with it quite nice (I would quote TortoiseSVN - n.a.: i am not associated
with), from the pov of Eclipse development there is no way I would migrate a project from cvs to
svn. (moreover I have the same feedback from IntelliJ IDEA users).
cheers,
:alex |.::the_mindstorm::.|
#: by Geoff Longman's words the mind was *winged* :#
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org