| [egit-dev] ResourceVariantTree should not return null on unchanged resources |
|
Hello EGit team,
I'm currently working on the integration of the logical model in EGit (based on the work of Laurent Goubet). I have some question regarding the behavior of GitResourceVariantTree object. Here is my use case: I have project holding 3 files. Project-1 Here is what I do 0. First I share this project (and all its files) into a git repository and I commit (C1). My history look like this. C1 [HEAD] C2 Where: My goal is to compare C1 with C2 (my HEAD is on C1). The logical model I'm using, basically adds all files with the extension ".sample" into the logical model. For example if I select "file2.sample" the logical model would be [file1.sample,file2.sample,file3.sample]. When I do compare those two revisions I do not succeed making a difference between the use case of the "file2.sample" and the "file3.sample". In both cases the resource variant is null. Indeed the current implementation of the synchronization is based on a cache that stores all the differences between C1 and C2 [1]. It is then used in the GitResourceVariantTree [2] to get the resource variant. My problem is that in both use cases it returns a null value [3][4]. It seems to be the expected behavior according to the tests [5] and [6]. However, I my use case I get twice a null value that means two different thing. In the first use case (file2.sample) it means that the file has not changed whereas in the second use case (file3.sample) it means the file is no longer in the repository. Am I missing something to differentiate these two use cases? I have pushed a draft review exposing this use case in a unit test: https://git.eclipse.org/r/#/c/34144/ Now if you agree on this subject, I see several way to solve this problem (if it needs solving). Maybe I could implement a way to force into the cache some values even if they have not changed. In our use case, force into the cache all the resources pointed by the logical model even if they have not changed. In our use case, I would force a entry on "file2.sample" since "file1.sample" and "file2.sample" are already in it. This way the resource variant would not be null anymore in the case of "file2.sample". I have pushed a draft for this solution proposal (it's sometime easier to read code than a long mail like this one): https://git.eclipse.org/r/#/c/34145/ Another solution might be to prevents the variant resource tree to return null if the resource is identical between two revisions (not yet implemented). The problem with this solution is that it might be costly if this use case happen often. Thanks for any feedback that you can give me on this subject. Regards, Arthur Daussy [1] https://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncCache.java#n156 [2] https://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java#n112 [3] https://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java#n114 [4] https://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java#n119 since the return objectId is ObjectID.zeroId() [5] https://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java#n200 [6] https://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java#n171 |