I did not see your original request back in February. Thanks to Gmail, I
see it now.
When you add something to ignore list it modifies the svn:ignore property.
Like any other change to your working copy you need to commit this change.
Until you do, it shows as an outgoing change.
What you see in the Synchronize view is not a Subversion conflict, you are
seeing a Synchronize conflict. You will see this anytime there is both an
incoming and outgoing change for the same item. It does not mean there is a
conflict, it means there might be a conflict.
FWIW, we have no control over the UI of the Synchronize view. It comes from
Eclipse itself. We simply provide the info that there is a change and it
present the UI.
We control the decorators we place on views like the Package Explore. Since
there is no SVN conflict, you would have seen a modification indication that
there is a change to commit, as opposed to the conflict decorator.
On Thu, Aug 11, 2011 at 12:58 PM, Brandon Mayes <bdmayes_at_gmail.com> wrote:
> For anyone interested I think that I have resolved this issue while a
> co-worker of mine was fixing a different issue with his Subclipse setup.
> The underlying cause appears to be the properties file itself (where SVN is
> storing the ignore list). Subclipse is displaying a conflict because the
> .svn/dir-prop-base file has been modified (entries were added to the ignore
> list). This doesn't seem to show up as a conflict on the command line so I
> think this is actually a bug with Subclipse (i.e. there is not a one-to-one
> mapping between the behavior of command line SVN and Subclipse). I don't
> think Subclipse should be reporting differences on the properties files but
> I have found a workaround.
>
> To resolve this issue I simply committed the directory to SVN after
> ignoring files which (under the covers) is actually committing the new
> properties file. So the steps would be something like:
>
> 1. checkout the project
> 2. run builds or whatever, and then add all of the files you want to the
> svn:ignore list
> 3. without any changes to the source files anywhere, commit the top level
> directory (or any directory showing conflict) back to svn.
>
> I'm actually not sure if you need to have zero changes between the source
> files or not, but I did that just in case. When the directory gets
> committed back to SVN it is actually just committing the properties on that
> directory, so it's really committing the new .svn/dir-prop-base. Now
> Subclipse no longer reports a conflict because the two files are the same.
> If you update the ignore list at any point I think you're going to run into
> this issue again though.
>
> The problem with this "solution" is that it means you have created a global
> ignore list. Anyone checking out your project will have the same ignore
> list, and maybe some people want to ignore different files? If so I suppose
> they can always modify the ignore list themselves. I did this in Linux by
> changing the default editor (I would prefer vim over nano) and running the
> propedit command like this:
>
> $ export SVN_EDITOR=vim
> $ svn propedit svn:ignore .
>
> ------------------------------------------------------
>
> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2815764
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subclipse.tigris.org].
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2815767
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2011-08-11 19:04:36 CEST