[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: RE: Re: AW: Re: Modification Badge still there after COMMIT

From: Markus Karg <markus.karg_at_quipsy.de>
Date: 2005-09-30 12:30:37 CEST

thanks for the link, but actually my problem is that our developers are using Subclipse ONLY and do not have knowledge of the Subversion command line tool -- that's why I asked this question in the Subclipse list but not in the Subversion list. Actually there is a "rename" function in Eclipse, so that function should "talk" in some way to Subclipse that makes Subclipse perform the steps described in the FAQ. :-)
Mit freundlichem Gruss / With kind regards
Markus KARG, Staatl. gepr. Inf.
Entwicklung / R & D


Von: Martin Letenay [mailto:mle@whitestein.com]
Gesendet: Fr 30.09.2005 12:26
An: users@subclipse.tigris.org
Betreff: RE: Re: AW: Re: Modification Badge still there after COMMIT

For c) - case change - see subversion FAQ - http://subversion.tigris.org/faq.html#case-change


        From: Markus Karg [mailto:markus.karg@quipsy.de]
        Sent: 30 September 2005 12:17
        To: users@subclipse.tigris.org; users@subclipse.tigris.org
        Subject: AW: Re: AW: Re: Modification Badge still there after COMMIT
        I've read the subversion book but it didn't cover number (c).
        Maybe a svn bug?
        Mit freundlichem Gruss / With kind regards
        Markus KARG, Staatl. gepr. Inf.
        Entwicklung / R & D


        Von: Denny Valliant [mailto:valliant@unm.edu]
        Gesendet: Fr 30.09.2005 11:11
        An: users@subclipse.tigris.org
        Betreff: Re: AW: Re: Modification Badge still there after COMMIT

        Markus Karg wrote:

> Mark,
> okay, so I have checked with the command line tool: cvs status tells
> me some interesting things:
> (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?
> (b) Same happens for the folder 'bin'. Actually I cannot see that
> folder in the Java project since Eclipse handles that folder internally.
> (c) One file was changed from lowercase to uppercase. Subclipse keeps
> that file marked as "to be deleted" when doing svn status.
> The reason for all of that might be (again) that the project was
> stored in Microsoft's VSS before: VSS doesn't care for
> upper/lowercase. After manually putting the source into SVN by the svn
> command line tools, in Eclipse I just disconnected the project from
> VSS and then did "Team/ShareProject/SVN". Maybe this was the wrong
> way? I didn't want to clear the sources locally, but maybe doing that
> and afterwords doing a new checkout would have prevented this.

        Most of this stuff is covered in various FAQs and documentation for both
        subversion and subclipse.
        I liked the subversion book. Just the fact that it was there was kewl.
        The bit about deleteing the
        renamed file is odd I think. Did the command SVN say the same thing?
        Hrm... ***

        Some people like to save .project and such (not bin, probably) in the
        repository. Unless you add
        the file to svn:ignore it will come up as being needed to be committed.
        to quote Marc:
        -1. An unversioned but not svn:ignore-d file is dirty -- action needs
        to be taken on that folder.
        If you want to suppress the dirty flag for that file, you should
        svn:ignore it.

        You probably don't want to commit any directory that eclipse regularly
        deletes, as the .svn folder
        with all the metadata will get deleted as well.


        I'm getting sleepy, so I could be wrong;
        Like my email's formatting... :-)

        To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
        For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Sep 30 20:30:37 2005

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.