[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Subclipse-users] Project Import shows no decorations

From: DM Smith <dmsmith555_at_yahoo.com>
Date: 2006-01-20 14:38:19 CET

Hi,
    I have a single repository with many subdirectories in trunk, where
each is a separate Eclipse project. I was expecting for a commit against
two or more of these projects to be atomic. Instead, each project is
committed independently. If I do the commit from the command line or if
I use another tool, they are atomic. Someone has suggested using JavaSVN
rather than JavaHL, so that is next.
    One thought that I had regarding this is that there is no .svn for
the workspace. No common root for the checkouts. So I started over. From
the command line I checked out trunk into a directory, giving it a name
of my choice, say "c:\Eclipse\NewWS". As expected, this got every
Eclipse project into the right place. I then started Eclipse and then
did an Import -> Existing Projects in Workspace, browsing to that
directory and clicking finish. The import worked just fine and Subclipse
seems to work too, but there are no decorations.
    Is this a bug?
    While I am at it, let me describe my recent experiences. I have been
using SVN for over a year now to manage SQL at work. I have been using
Eclipse for many years and also WSAD. And a while ago I worked on a java
project. I did my work within Eclipse, but at that time Subclipse was a
bit too raw for my liking. So at that time, I did the SVN work from the
command line. This month we migrated our open source project,
http://www.crosswire.org/jsword from CVS to SVN. And I downloaded the
most recent version of Subclipse (104 and then upgraded to 105).
    Since we are now in SVN, we could do those directory changes which
we avoided because CVS would have lost history. But my experiences with
Subclipse were frustrating. Most of it I chalked up to not understanding
how Subclipse integrated. But part of my frustration was based upon my
positive experiences using TortoiseSVN for the last year. It is hard not
to do a comparison and hard not to expect the same experience or better.
I know that it is not fair. Especially because Subclipse is integrated
into an IDE. But here are some of my frustrations:
    I expect copy to simply be a copy unless I explicitly want to
branch. I could find no way to do this except to use an ignored
directory as an intermediate staging ground. Many times I want to
practice reuse by starting with a pattern that is close. There is no
reason to tie the file's origin to the original. Other times I want for
two files to have the same content (.e.g. the per project preference
settings in Eclipse) To do this I have to open both files and copy the
internal text from the one into the other. TortoiseSVN has a right mouse
drag/drop context menu popup which allows me to move, copy, ... in SVN
or within the OS.
    I did a lot of directory refactoring and kept encountering locking
errors. These were operations that I have done repeatedly from the
command line or with TortoiseSVN. But once it got the problem, it would
not even work from the command line. The upshot was that I found it
easiest to start all over again. I ended up doing many small
refactorings or refactoring from the command line.
    I also ran into the problem where a file or directory was scheduled
for deletion and I was not ready for that to happen. But I could not
revert it. And it got in the way.
    Again most of this I chalk up to being new to Subclipse.
    Anyway, I don't think Subclipse is quite ready for 1.0. But it is
quite usable.
Hope this helps,
    DM Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Jan 20 14:38:42 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.