DM Smith <dmsmith555@yahoo.com> wrote on 01/20/2006 08:38:19 AM:
> 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.
JavaHL does not provided this feature, JavaSVN does.
> 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?
Most likely you have run into this:
http://subclipse.tigris.org/faq.html#path-case
However, if you are on Eclipse 3.0, be aware that after you import the
projects you still have to do Team -> Share project to attach them to
Subclipse. In Eclipe 3.1, they are auto-shared on import.
Also, it is not entirely clear what you did, but the Eclipse workspace
folder itself should NOT be a Subversion WC. There is documentation in
the online help about doing what you want to do. It sounds like that is
what you did, but I just want to make sure. The Eclipse workspace folder
would essentially be empty if you looked at it on the filesystem, but it
is pointing to all of these projects in another folder.
> 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.
If you are talking about copying stuff locally in your workspace you have
to use the Copy option provided on the Team menu. The Eclipse copy
operations do not notify us about the copy so we are not able to do it in
SVN. This is similar to how you have to use the TortoiseSVN copy option
and not the Windows copy option. This mainly applies to folders. If you
want to copy a file without history you can just copy it.
I am not sure about your branch comment, but branches and copies are the
same thing. We call the option Create Branch/Tag because that is what
most people want to do and if we just called the option Copy most users
would not know that is how you create a branch/tag in Subversion.
> 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.
There are plenty of refactorings that Subversion does not support. Usually
doing commits between each refactoring will work. Also, JavaSVN has some
intelligence in this area that JavaHL does not, so you might get better
results if that is your adapter.
Regardless, if you think there is a problem you need to provide a
reproduction recipe.
> 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.
I have no idea what you are talking about here, a detailed recipe would be
needed.
> Again most of this I chalk up to being new to Subclipse.
> Anyway, I don't think Subclipse is quite ready for 1.0.
I couldn't disagree more.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Jan 20 15:15:48 2006