Well, sorry to top post - I'm gonna veer from the subject.
First off, if you are copying stuff and want to have the history of what
you are copying available in the copy as well (one of the kewl things
about this VC stuff) you allways want to be sure you are doing a SVN
copy, and not just removing the .svn folder when you copy.
If you don't care about history then sure, delete the .svn stuff and
you will be able to commit the copy as new. When you copy the .svn, you
are really making more of a symbolic link, as any stuff you do to the
copy will reflect in the original, if I'm thinking right. Not really
making a copy. It can really mess you up if you perform actions thinking
it's really a copy.
The reason this happens is because of an Eclipse quirk, where the copy
command isn't very "hookable". I think we are waiting for Eclipse to
get a fix in, and trying to think of workarounds currently. Some kind of
check as suggested.
Now for the veer: Even if Eclipse fixes this at some point, we will
still have to support the broken version until we cycle through it,
right? So there is still gonna need to be some kind of workaround
incorperated. At the least some kind of alert box or some such. I just
think it's messy and so hasn't been tackled yet? I haven't checked the
status or existance of the issue in the tracker, so I'm unsure of
current state.
I'll try to figure it out, but I'm such a noob... at any rate the
ctrl+c/ctrl+v is such an ingrained action, a stab needs to be taken at a
solution of some sort. Real Soon Now. :-P. Or not. Just thinking that as
use grows, this will be an issue that keeps popping up, as it will bite
everyone at least once (I'm guessing. As I haven't seen too many of
these type posts, maybe it's not that big a deal).
Bah. Never mind. For Smith: Use SVN copy/paste whenever possible, or the
export option otherwise. I'm pretty sure you can un-hide the .svn files,
but I can't remember where. Look more under Eclipse type stuff than
Java type stuff I'd guess. If I find the exact place I'll let ya know.
Thanks,
:Denny
DM Smith wrote:
> I am wondering what is the best way to copy a directory from one
> project to another such that it can then be added to that project's
> source code control. In Eclipse, I have set up per project "Java
> Compiler" settings. This creates a .settings folder with a couple of
> files in it. Because I want the same settings for a new project, I
> want to copy the folder from the one project to the other. Also, these
> projects are not in the same SVN repository.
>
> Using Ctrl-C and Ctrl-V works very badly as it also copies the .svn
> directory and leaves Subclipse very confused. More on that in a bit.
>
> I then tried copying the directory from the command line and then
> deleting all the .svn directories I could find. I had to do a refresh
> to make Eclipse see it.
>
> Then I tried Export, and while that works, it does so outside of
> Eclipse. Again, a refresh is in order.
>
> Traditional Ctrl-C and Ctrl-V qualifies as a "don't do that". The
> following is not a bug or a real problem, but description of
> Subclipse's interaction with this "don't do that". And I guess, at the
> end I suggest that improvements can be made. I think it should be
> possible to recover using Subclipse.
>
> When I do a copy and paste of the .settings directory from one project
> to another, it shows up as being in the repository, when in fact it is
> not. When I look in the repository via SVN Repository Explorer, it
> correctly shows that it is not present. If I try a commit on the
> project, it declares that nothing was changed. If I make a simple
> change to any other file and commit the project only that change shows
> up.
>
> When I try to delete the pasted .settings directory, it disappears
> from view and it is scheduled for deletion in SVN. The project folder
> is decorated with a "*" showing that something was modified. If I do a
> revert on the project, it does nothing. If I hit refresh, the folder
> shows up decorated with an "X" showing it is marked for deletion. If I
> try to revert the project again, nothing happens.
>
> Now, if I revert the .settings folder, I get the following error:
> revert -N C:/JSword/common-swing/.settings
> Reverted C:/JSword/common-swing/.settings
> revert -N C:/JSword/common-swing/.settings/org.eclipse.jdt.core.prefs
> svn: Error restoring text for
> 'C:\JSword\common-swing\.settings\org.eclipse.jdt.core.prefs'
>
> When I look into the .settings folder it is empty. The other file did
> not make it back either.
>
> I can delete the .settings folder again and it won't go away.
>
> I tried svn clean, but it didn't help.
>
> My only solution is to go to the OS and manually delete the .settings
> directory or to use the DeferFileDelete property.
>
> I'm not sure what the right behavior should be, but I think should be
> able to do the delete from within Eclipse with Subclipse as it comes
> "out of the box"
>
> In this instance I wanted to be able to get at the .svn directory
> within Eclipse to delete it, but it is filtered from view and I don't
> see an option for it in the filter menu of the java perspective. I
> guess I am suggesting that the .svn directory appear on the Java
> Perspective's Filter View list as a separate entry. Yes it is
> dangerous, but then again, I can always get to it from the file system.
>
> Doesn't the .svn directory hold some knowledge what it is connected to
> that could be used invalidate or remove the .svn directory so that the
> copy would work? So when an operation is started on an element could
> it be checked against the .svn and if found in error, offer solutions
> for the user to pick from?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sat Jan 21 06:48:55 2006