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
|- file1.sample
|- file2.sample
|- file3.sample
Here is what I do
0. First I share this project (and all its files)
into a git repository and I commit (C1).
1. I change the content of file1.sample.
2. I do NOT change the content of file2.sample.
3. I delete file3.sample.
4. I add and commit my changes (C2).
My history look like this.
C1 [HEAD]
C2
file1.sample -|-------[+]--------|---[X]---|-->
file2.sample -|-------[+]--------|----------|-->
file3.sample -|-------[+]--------|---[/]----|-->
Where:
+ means add the file
/ means remove the file (and delete it).
X means the file has changed
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