Possible to sync on ILocalChange creation from resource chan
3 answers
When changes are made to a resource I guess a resource change listener
creates ILocalChanges from them - from which checkin/deliver can be
performed.
That's not true, the changes that are made go through our EFS provider
which in addition to the change on the filesystem updates the metadata
accordingly. The ILocalChanges are then computed from the metadata.
Is there any way to sync on the creation of ILocalChanges
from the resource changes?
I do not understand what you're asking. Could you please explain what
you're trying to do?
- Dmitry
What we are trying to do in our tooling is as follows
1. Make changes to a file, save it.
2. See if the file needs to be checked in by calling
ILocalChangeManager.getPendingChanges(IShareable[]) 3. If there is a
ILocalChange, check it in with NewCheckInOperation() 4. Deliver the
changeset containing that file by calling
IWorkspaceConnection.deliver(IChangeHistorySyncReport, List, List,
IProgressMonitor)
The problem we seem to be facing is that an unchecked-in change shows up
in the pending view for that file after we finish the steps above. Put
another way we dont seem to be seeing a change (in step 2), for the
change we made in step 1.
Please advice if there is a better way to guaranteed check-in and
deliver changes in your workspace using API.
before step 2, call ILocalChangeManager.syncPendingChanges(). Make sure
you are not holding any eclipse resource locks when you call that method.
- Dmitry
What we are trying to do in our tooling is as follows
1. Make changes to a file, save it.
2. See if the file needs to be checked in by calling
ILocalChangeManager.getPendingChanges(IShareable[])
3. If there is a ILocalChange, check it in with NewCheckInOperation()
4. Deliver the changeset containing that file by calling
IWorkspaceConnection.deliver(IChangeHistorySyncReport, List, List,
IProgressMonitor)
The problem we seem to be facing is that an unchecked-in change shows up
in the pending view for that file after we finish the steps above. Put
another way we dont seem to be seeing a change (in step 2), for the
change we made in step 1.
Please advice if there is a better way to guaranteed check-in and
deliver changes in your workspace using API.
Regards,
Sri.
Dmitry Karasik wrote:
1. Make changes to a file, save it.
2. See if the file needs to be checked in by calling
ILocalChangeManager.getPendingChanges(IShareable[])
3. If there is a ILocalChange, check it in with NewCheckInOperation()
4. Deliver the changeset containing that file by calling
IWorkspaceConnection.deliver(IChangeHistorySyncReport, List, List,
IProgressMonitor)
The problem we seem to be facing is that an unchecked-in change shows up
in the pending view for that file after we finish the steps above. Put
another way we dont seem to be seeing a change (in step 2), for the
change we made in step 1.
Please advice if there is a better way to guaranteed check-in and
deliver changes in your workspace using API.
Regards,
Sri.
Dmitry Karasik wrote:
When changes are made to a resource I guess a resource change listener
creates ILocalChanges from them - from which checkin/deliver can be
performed.
That's not true, the changes that are made go through our EFS provider
which in addition to the change on the filesystem updates the metadata
accordingly. The ILocalChanges are then computed from the metadata.
Is there any way to sync on the creation of ILocalChanges
from the resource changes?
I do not understand what you're asking. Could you please explain what
you're trying to do?
- Dmitry