Kevin Duffey <supreme_java_guru_1@yahoo.com> wrote on 09/07/2005 05:24:21
PM:
> Sorry if this is confusing, but I am at a loss. I keep
> on seeming to have issues that never happened with CVS
> and am starting to get discouraged with
> subclipse/subversion. I am spending too much time
> trying to figure out why these things keep happening.
> I know its not perfect, and its free, but maybe its
> time to go back to CVS for a few more months until a
> 1.0 is released for Subclipse? I really want the
> atomic commit and the ability to rename folders/files
> without problems in subclipse, but at the expense of
> hours evey week debugging issues, I can't justify to
> my boss these issues.
I do not mean to sound harsh but it sounds like you have not put much up
front effort into understanding Subversion and the differences between it
and CVS. In order to get some of these features you want to have,
Subversion imposes a lot tighter restrictions on what it calls the
"working copy". One of the great advantages to CVS is that being a purely
file-bases system it is possible to arrange those files in any way you
want. Also you can generally manually manipulate them however you want in
your local work area and just sort it out later. Subversion wants to know
about these operations so that it can version then, and you can undo them
etc...
Your problems are a bit too confusing to try to directly answer right now.
Let me arm you with some information that at a minimum should allow you
to focus your questions a bit in any followups.
1) A folder in a Subversion working copy contains a hidden subfolder
named .svn. This is what makes it a working copy. This .svn folder
contains a lot of information. When you copy a folder, especially when
using your native file system, you probably do not want to copy the .svn
folder with it, but that is typically what happens. Any folder that has a
.svn folder inside it is essentially a mini-working copy. So if you copy
the .svn folder you copy all of the svn information with it.
2) If the copy is all happening within a Subversion working copy, then
you want to use the svn copy command. This allows Subversion to do the
copy correctly and update all of its internal metadata. Within Eclipse,
we try to capture these copy operations, but to my knowledge, we cannot
capture all of them. This is Eclipse's fault. The way this works in
Eclipse is that we register with Eclipse to be notified of
copy/move/delete operations. It is then up to Eclipse to do that. For
most UI operations it does, for some it doesn't. If you have the SVN
Console view showing you should be able to see the copy/move commands
logged when they are executed by Subclipse.
3) When you delete a folder in a Subversion working copy using your file
systems delete command, you can break your working copy in a way that is
difficult to undo. When you use the svn delete command, the folder is
"scheduled for deletion". The folder will remain in place until you
commit the delete. With Subclipse, this is when you see the red X on the
folder and that is why it does not go away.
4) The commands svn move and svn rename are really just an svn copy
followed by an svn delete. As in the case of #2, Eclipse will typically
notify us of a rename/move so that we can run the svn commands. That
explains why you saw the red X in one of your scenarios.
It seemed like the root of your problem was at the beginning with the
copy. What we would want to nail down is what you were trying to do. Were
you wanting to do an svn copy to copy a folder from one area within a
workspace to another area within the same workspace or were you really
just trying to do a filesystem copy. If it is the latter, you can
typically resolve the problem by removing any .svn folders from inside the
folders you copied. This should make all of the resources shows up as
unversioned, which will allow you to add them.
You might also want to look into whether you should be using svn:externals
for some of this. This feature lets you reference a given folder
structure from several different places in your repository.
Finally, once we know what you wanted to do, we have to see if it can be
done right now inside Eclipse, and if it can't we would need to
investigate whether Eclipse provides the info we need and we are just not
handling it correctly, or if Eclipse just doesn't handle this scenario. In
theory, copy & paste and/or drag and drop within a project should be able
to trigger and svn copy, as it does for a move. In my quick tests, that
does not seem to be the case, and Eclipse seems to be doing a normal
filesystem copy which would be incorrect.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Sep 8 11:01:37 2005