Subversion integration

Hi.

For a month now I've been using Subversion integration in IntelliJ in
addition to Tortoise and SmartSVN (clients for Subversion).

I was having Subversion problems (cleanup, checksums, etc.) all the time
where the other team members had very little to none.

It seems that the differentiator between me and the other people here
was the IntelliJ Subversion integration, so I turned it off to see if my
problems stop. I don't know it's IntelliJ, but that's what I am set
off to verify.

I have 2 questions at this point:

1. Has anyone else had problems (other than known bugs like renaming
files) with a Subversion environment when using Irida Subversion
integration?

2. JetBrains - Is my suspicion founded? Is the Subversion plug-in known
to break the .svn directory information or cause other problems?

Amnon

5 comments
Comment actions Permalink

In article <d1usut$52n$1@is.intellij.net>,
"Amnon I. Govrin" <nomail@jetbrains.com> wrote:

Hi.

For a month now I've been using Subversion integration in IntelliJ in
addition to Tortoise and SmartSVN (clients for Subversion).

I was having Subversion problems (cleanup, checksums, etc.) all the time
where the other team members had very little to none.

It seems that the differentiator between me and the other people here
was the IntelliJ Subversion integration, so I turned it off to see if my
problems stop. I don't know it's IntelliJ, but that's what I am set
off to verify.

I have 2 questions at this point:

1. Has anyone else had problems (other than known bugs like renaming
files) with a Subversion environment when using Irida Subversion
integration?

2. JetBrains - Is my suspicion founded? Is the Subversion plug-in known
to break the .svn directory information or cause other problems?


Yes
This is something I just went back and forth EXTENSIVELY with Alex at
Tmate. We finally discovered where the bug is. I can reproduce this
consistently.

The issue is that if you have something like $Revision$ in your java
file, and you proset svn:keyword "Rev" on it, javaSVN seems to choke on
it, and cause a mismatch on the file making it impossible to check it
back in.

FURTHER (JETBRAINS READ THIS) the easiest way to reproduce this is to:

1- Move the file (F6)
2- ctrl+z to undo the move
3- Commit the whole package the file was in
4- edit the file in its current location
5- commit the file... BOOM .svn dir corruption.

ONE of the problems, besides the prop* issues of javaSVN is that when I
do a ctrl+z, or command + z on the Mac, idea just undoes the move, but
it doesn't call javaSVN to undo it. That's just bad, you can't treat
Subversion like you treat CVS. There is a lot more going on in there.

I am almost thinking that JetBrains should yank the subversion plugin
until such time that those who are writing the code for it, can COMPLETE
IT.

I've corrupted a repository with that plugin, and that's just not cool.

R

0
Comment actions Permalink

I've corrupted a repository with that plugin, and that's just not cool.


Scary :(

I haven't had the 'chance' to experience these problems yet, but for
me the Subversion integration doesn't seem to be doing much:

- it doesn't seem to agree on what the status of a file or a directory
is (everything is always 'up to date' when real SVN reports
modified directories, unknown files etc)

- the Show Diff doesn't do anything even though the file has clearly
been modified

- Show History works only after manually fixing the ClassCassException
that it throws all over the place.


Vince.



0
Comment actions Permalink

On Thu, 24 Mar 2005 10:21:30 -0700, Amnon I. Govrin wrote:

2. JetBrains - Is my suspicion founded? Is the Subversion plug-in known to
break the .svn directory information or cause other problems?


I did have one situation last month when IDEA broke the repo during an SVN
move. I believe I reported that incident, but at the moment I can't
remember..

0
Comment actions Permalink

On Thu, 24 Mar 2005 13:25:44 -0500, Robert S. Sfeir wrote:

I am almost thinking that JetBrains should yank the subversion plugin
until such time that those who are writing the code for it, can COMPLETE
IT.


Thats understandable, but I've always heard it said (unofficially) that
you shouldn't really use EAPs against your production code unless you're a
masochist, or trusting.

99% of the time we're trusting, but we do need to remember that EAP is an
"in development" project.

But I hear ya....

0
Comment actions Permalink

In article <pan.2005.03.24.18.57.39.378610@gmail.com>,
Mark Derricutt <talios@gmail.com> wrote:

On Thu, 24 Mar 2005 13:25:44 -0500, Robert S. Sfeir wrote:

I am almost thinking that JetBrains should yank the subversion plugin
until such time that those who are writing the code for it, can COMPLETE
IT.


Thats understandable, but I've always heard it said (unofficially) that
you shouldn't really use EAPs against your production code unless you're a
masochist, or trusting.

99% of the time we're trusting, but we do need to remember that EAP is an
"in development" project.

But I hear ya....


Well DUH, and thanks for the sermon. You don't see me jumping up and
down and complaining to jetbrains that they screwed it up. It is my
responsibility for hitting my repo with it, not theirs, and I always
back up, so no data lost, but did manage to corrupt the repo and .svn
dir and I'm letting you all know.

I'm saying that this plugin right now is darn right dangerous, half
implemented (half-ass tested too), and considering how different
Subversion functionality is compared to CVS, and considering that the
functionality is supported by a situation that causes a double whammy:
javaSVN does the processing, IDEA puts in the hooks and logic and
interface, there is no way to tell who what when where without A LOT of
testing and debugging. It took me the better part of 8 hours of
debugging and trying things before I finally got a concrete repeatable
example to Alex, who then tested some more and discovered that besides
problems with prop*, the IDEA undo does not hit javaSVN, so javaSVN has
no idea something changed, it just thinks the file was somehow added to
this location, instant loss of history too... oops.

There are too many parties involved in this, and the functionality is
not complete and the workflow required just doesn't work right. Furhter
the ticket we had submitted is now closed as fixed, and this is very
disturbing.

I'm suggesting that the plugin be yanked, before some poor soul who is
not used to EAP'ing yanks his own code apart and ends up completely
upset. Yes people should pay attention while EAPing (I do), but telling
them oops sorry chump at every turn with the subversion plugin is just
not cool especially if we KNOW it's busted.

Since we KNOW it's busted, and we KNOW it will cause repository
corruption, and we KNOW it will cause .svn dir corruption, and it is
obviously not a high priority right now for JetBrains to complete the
plugin, I am suggesting they yank it.

Thanks.
R

0

Please sign in to leave a comment.