[email protected]
[Top] [All Lists]

Re: FYI: SVN Observations

Subject: Re: FYI: SVN Observations
From: Colin Sampaleanu
Date: Sun, 10 Jul 2005 08:40:22 -0400
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).

: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

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.


To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

[email protected]----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

<Prev in Thread] Current Thread [Next in Thread>