[Subclipse-users] BUG: file renames don't always have a MOVE_TO or MOVE_FROM IResourceChangeEvent data

Hello,

We are running into an issue with the IResourceChangeEvent
notifications we get when a project is managed by subclipse. File
renames for non-committed changes lack the MOVE_TO (and/or MOVE_FROM)
attributes whenever the renamed file has not been committed into
subversion.

In terms of our application, this behaviour is catastrophic because
it makes it impossible for us to determine that the file was moved.

When project is NOT under subclipse revision control, and the user
renames a file, we get the following IResourceChangeEvent.POST_BUILD
resource change delta:

a) we get an IResourceDelta.REMOVED, with the flags
IResourceDelta.MOVE_TO set, so we can the 'old' path, and the one the
resource was moved to.
b) We also get the IResourceDelta.ADDED notification.

Here's what it looks like when we print the notifications from our
listener on a project that is NOT subclipse managed:

MOVED_TO from: /BAR/B.person to: /BAR/C.person
ADDED: /BAR/C.person

MOVED_TO from: /BAR/C.person to: /BAR/D.person
ADDED: /BAR/D.person

MOVED_TO from: /BAR/D.person to: /BAR/E.person
ADDED: /BAR/E.person

MOVED_TO from: /BAR/E.person to: /BAR/F.person
ADDED: /BAR/F.person

When the files are under subclipse the notifications are similar so
long as each rename is followed by a commit. If the commit, is not
provided, and the recently renamed resource is renamed again, the
notifications are simply a delete and an add. The move information is
not provided in the resource delta.

MOVED_TO from: /foo/B.person to: /foo/C.person
ADDED: /foo/C.person
[OK - followed by a commit]

MOVED_TO from: /foo/C.person to: /foo/D.person
ADDED: /foo/D.person
[OK, D is scheduled for add, but not commited]

REMOVED: /foo/D.person
ADDED: /foo/E.person

[BAD, the we get a removed notification without either the MOVE_TO or
MOVED_FROM flags set)

We would like subclipse to provide MOVE_TO (or MOVE_FROM) information
in their notification. We have verified that under other team
providers (perforce being the one we tested) we don't observe this
behaviour.

Thanks,

/alberto ricart

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Mon Aug 21 22:34:50 2006