Mark,
Very fare reply! You are correct, I have not spent a
lot of time and I actually have a book to read,
Prgamatic Subversion or something like that. I
apologize for the post without truly understanding the
differences. You are correct in that I should
read/learn how to use subversion before barking about
it not working.
In reply to your 5 steps, essentially I was using
Eclipse to make a file system copy of a folder and its
subfolders/files to a new folder in another location.
It appears that Subclipse picked up on the copy/paste
and added the folder into subversion under the new
folder location automatically, aka the svn copy? I
didn't know it was able to do that. I also don't see a
right-click delete or copy/paste option under the
team-> pull out menu, so I am not sure how I can
directly svn delete or svn copy something from inside
of eclipse?
Good news is.. I did an update which brought back the
unwanted folder, then right-clicked, deleted which
shows the red x, then did a commit on the parent
folder and it worked! Now I know how to delete a
versioned file/folder. In CVS I am use to just
deleting whatever, then commiting the parent folder
and the deleted stuff is moved to the attic.
Thanks again for not blasting me and explaining
instead!
--- Mark Phippard <MarkP@softlanding.com> wrote:
> 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.
>
>
_____________________________________________________________________________
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail:
> users-help@subclipse.tigris.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Received on Thu Sep 8 13:37:55 2005