In general update to exactly the same revision should take a very small time. However, there are situations when repository revision has changed, but no modifications are made (received) during update:
E.g, file were changed at /repos/project1/file.txt (this increases repository revision number), and then user updates working copy checked out from /repos/project2/ - Subversion client have to update all stored revision numbers to the latest one despite there are no actual changes in the working copy (project2) - this is standard Subversion behaviour. When two or more subsequent updates are made, second update usually takes significantly less time than the first one.
The following workaround could help to resolve this issue: keep each module in a separate project, so that there are no situations when revision number increases and nothing actually changes in the project.
Other options requires changes in the library that could make it not fully compatible with the native client. I will discuss that with Dmitry.
Alexander Kitaev - 09 Feb 07 17:00 We've discussed this problem with Dmitry:
In general update to exactly the same revision should take a very small time. However, there are situations when repository revision has changed, but no modifications are made (received) during update:
E.g, file were changed at /repos/project1/file.txt (this increases repository revision number), and then user updates working copy checked out from /repos/project2/ - Subversion client have to update all stored revision numbers to the latest one despite there are no actual changes in the working copy (project2) - this is standard Subversion behaviour. When two or more subsequent updates are made, second update usually takes significantly less time than the first one.
The following workaround could help to resolve this issue: keep each module in a separate project, so that there are no situations when revision number increases and nothing actually changes in the project.
Other options requires changes in the library that could make it not fully compatible with the native client. I will discuss that with Dmitry.
Performance Problem
Open
Faster update if a working copy is at the latest revision
In general update to exactly the same revision should take a very small time. However, there are situations when repository revision has changed, but no modifications are made (received) during update:
E.g, file were changed at /repos/project1/file.txt (this increases repository revision number), and then user updates working copy checked out from /repos/project2/ - Subversion client have to update all stored revision numbers to the latest one despite there are no actual changes in the working copy (project2) - this is standard Subversion behaviour. When two or more subsequent updates are made, second update usually takes significantly less time than the first one.
The following workaround could help to resolve this issue: keep each module in a separate project, so that there are no situations when revision number increases and nothing actually changes in the project.
Other options requires changes in the library that could make it not fully compatible with the native client. I will discuss that with Dmitry.