Mark,
actually our source code is not "Eclipse specific": We have other people modifying the same source with different tools. Those people need other project files. So either everyone is able to maintain every project file (what is not possible: Eclipse users don't know about JBuilder project files and vice versa) or we omit from posting project files in SVN. So we decided not to have those in SVN, which is the "clean" way (as the source is 100% pure Java then). That means, I have to change perspective to resource, ignore the files, go back to Java perspective. That's not nice. :-(
For the rename problem: Cannot Subclipse take note of the rename action in Eclipse? Actually I have not renamed manually on disk, but used Eclipse's menu for that. So subclipse could take the necessary steps?
Mit freundlichem Gruss / With kind regards
Markus KARG, Staatl. gepr. Inf.
Entwicklung / R & D
QUIPSY QUALITY GmbH
________________________________
Von: Mark Phippard [mailto:MarkP@softlanding.com]
Gesendet: Fr 30.09.2005 14:56
An: users@subclipse.tigris.org
Betreff: Re: Modification Badge still there after COMMIT
"Markus Karg" <markus.karg@quipsy.de> wrote on 09/30/2005 02:00:01 AM:
> okay, so I have checked with the command line tool: cvs status tells me
some
> interesting things:
I assume you mean svn status, not cvs.
> (a) .classpath and .project are marked with a question mark. Actually
those
> files are hidden in the Java perspective since they are Eclipse internal
> stuff. Subclipse seems to not know about the fact that those are not
user's source code?
I like to add those to the repository. It makes it easier for other
Eclipse developers to checkout your project. If you do not want to add
them ever, then you should add them to svn:ignore.
> (b) Same happens for the folder 'bin'. Actually I cannot see that folder
in
> the Java project since Eclipse handles that folder internally.
Eclipse has some built-in stuff for ignoring things. I would still add
the bin folder to my svn:ignore. That way if you use TortoiseSVN or the
CLI you will never accidentally version it. Also, it makes the Subversion
API's a bit faster as they will not traverse into that folder.
> (c) One file was changed from lowercase to uppercase. Subclipse keeps
that
> file marked as "to be deleted" when doing svn status.
This is a design problem in Subversion itself. Martin already pointed you
to the FAQ. Subversion does not handle case changes on Windows very well.
There is nothing Subclipse can do to make this better.
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 Sep 30 23:21:14 2005