Mark Phippard wrote:
> 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.
>
Good. I'll give that a try.
>
>> 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
>
I took the defaults, which were to use the names that match the one's in
the repository. These visually match what was checked out. Was it that I
renamed trunk to NewWS that is causing the problem?
> 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.
>
I'm using 3.1.1 so they auto-shared.
> Also, it is not entirely clear what you did, but the Eclipse workspace
> folder itself should NOT be a Subversion WC.
So my NewWS folder has .workspace and a .svn folders and the folders
for each project. Does this cause problems? In the past I have often
stored project related stuff in that directory and have had no problems
with Eclipse. I was going to set svn:ignore for .workspace.
> 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.
>
Could you point me to the documentation. I have read the online FAQ, but
I could find very little otherwise. I have read the Subversion book from
cover to cover.
>
>> 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.
>
Some more details.
I went back and tried it again. And it worked as you said, if the
destination does not exist. I was under the impression that when I
copied a file in Eclipse that Subclipse was also copying the file. In
looking at it again, I could not figure out why I thought this; I was
wondering if I was seeing things and then I tried something else.
If I copy over top of another file by the same name in a different
folder and say yes to overwrite, it schedules the destination file for
delete. If I then commit, the file I copied remains, the underlying is
deleted. This surprised me in two ways: First, I did not expect the
scheduled deletion. Second, when the file was deleted, it remained.
To reproduce this is easy. Create two folders in two projects with the
same name, say "fred". Create a file in both with the same name, say
"george" but different content, say "file 1" and "file 2" respectively.
Commit that. Then Ctrl-C "george" containing "file 1" and then select
the other and do Ctrl-V. When prompted whether to overwrite, choose
"Yes". Verify that the content of the paste occurred, that the file is
scheduled for deletion and that the "X" decorator is present. Do the
commit and the pasted file is present but not under source code control,
this time decorated with a "?".
I tried this with both JavaSVN and javaHL, if that matters.
Delete's behavior surprised me. Using Eclipse's delete will schedule a
delete in SVN. And this bit me more than once. (Until I figured out that
it was happening) I had made a bunch of changes and wanted to start
over. My common pattern using TortoiseSVN did not work here. With that I
would just delete the files via the OS and then do an update, which
would bring back the original files. This was a lot easier than
reverting a bunch of individual files in different folders, as Windows
won't let you select files from across folders as Eclipse does. I was
expecting that the deletes would not automatically be scheduled for
deletion and that if I did a commit, they would be listed as missing
file, which I could select in the commit dialog, much as I can for files
not yet under source code control, indicating that they should be
deleted. I also expected to find a "delete" on the team menu.
>
>> 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.
>
Yeah, I knew better!
>
>> 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.
>
I'll see if I can reproduce it rather than avoid it. So for now never mind.
>
>> 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.
I am glad you are proud of your work. That drives quality! Subclipse is
most excellent, but it is not problem free. If a new user (but
experienced with Subversion and separately with Eclipse) can find one or
more problems on first use (that don't occur from the command line or
with TortoiseSVN) and documentation does not help (can't find it), is it
ready for 1.0? What it says to me is that I am going to find other
problems as I use it more. So, in my opinion, "almost." But, whether it
is 1.0 or not, I will still be using it.
Anyway, I have provided you with one concrete recipe of how to reproduce
a basic problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Jan 20 18:07:09 2006