Open heinrichreimer opened 1 year ago
Thank you for the feedback and making me aware of the issue.
Are you using the latest pre-release of the extension (1.11.10)?. I made some optimizations with how cvs status is used. I wonder if it addresses the issue you are encountering? If not, I'll certainly explore additional solutions.
Just installed the version but the issue persists. The problem is that with extssh:
as the CVSROOT
, each call to csv status
opens and closes a new SSH connection. So batching it would be preferable.
heinrich@reimer-thinkpad-x1-yoga:~/Webis$ cvs status research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-overview-datasets.tex
Host key fingerprint is SHA256:0+jMOwuXH1eGDE9+zECarg6DWVYp2gC86wNQb35jKws
+---[ECDSA 256]---+
| .. . |
| o. . + |
| . o. . o + o |
|. . o+ o + * = |
|. +. + S o = * |
|. . .=++ + + |
| oE oo+oB . . |
| o.. .*.o o |
| ..o +o. |
+----[SHA256]-----+
===================================================================
File: table-overview-datasets.tex Status: Up-to-date
Working revision: 1.1
Repository revision: 1.1 /srv/cvsroot/research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-overview-datasets.tex,v
Commit Identifier: 10063DFF83466DF34E9
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
heinrich@reimer-thinkpad-x1-yoga:~/Webis$ cvs status research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-performance-evaluation.tex
Host key fingerprint is SHA256:0+jMOwuXH1eGDE9+zECarg6DWVYp2gC86wNQb35jKws
+---[ECDSA 256]---+
| .. . |
| o. . + |
| . o. . o + o |
|. . o+ o + * = |
|. +. + S o = * |
|. . .=++ + + |
| oE oo+oB . . |
| o.. .*.o o |
| ..o +o. |
+----[SHA256]-----+
===================================================================
File: table-performance-evaluation.tex Status: Up-to-date
Working revision: 1.1
Repository revision: 1.1 /srv/cvsroot/research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-performance-evaluation.tex,v
Commit Identifier: 10063DFF83466DF34E9
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
heinrich@reimer-thinkpad-x1-yoga:~/Webis$ cvs status research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-overview-datasets.tex research-in-
progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-performance-evaluation.tex
Host key fingerprint is SHA256:0+jMOwuXH1eGDE9+zECarg6DWVYp2gC86wNQb35jKws
+---[ECDSA 256]---+
| .. . |
| o. . + |
| . o. . o + o |
|. . o+ o + * = |
|. +. + S o = * |
|. . .=++ + + |
| oE oo+oB . . |
| o.. .*.o o |
| ..o +o. |
+----[SHA256]-----+
===================================================================
File: table-overview-datasets.tex Status: Up-to-date
Working revision: 1.1
Repository revision: 1.1 /srv/cvsroot/research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-overview-datasets.tex,v
Commit Identifier: 10063DFF83466DF34E9
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: table-performance-evaluation.tex Status: Up-to-date
Working revision: 1.1
Repository revision: 1.1 /srv/cvsroot/research-in-progress/web-search/SIGIR-20/sigir20-oversampling-ltr-paper-submitted/table-performance-evaluation.tex,v
Commit Identifier: 10063DFF83466DF34E9
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
heinrich@reimer-thinkpad-x1-yoga:~/Webis$
Notice how the SSH host key is displayed only once (i.e., only one connection is made) in the last call to cvs status
despite showing the status of bot files.
Thank you for the extra details. I've been thinking about your request, but I'm not sure yet that batching is a better solution than what is currently implemented.
The extension should only be calling "cvs status" when a file is opened in the active editor. The results from "cvs status" are cached. So the next time the file is viewed there should be no "cvs status" request to the server. If the repository is refreshed, all the cached results are cleared and a "cvs status" will be required again if the file is opened/viewed.
I work with some very large remote pserver repositories and I've found that this solution, while not perfect, works well. I'm worried about changing the design of the extension to get the status of ever file in the repository at startup because if the repository is very large there will be a significant cost to the startup time plus the overhead of managing a very large cache.
I appreciate that on a slower connection to a server this design may not be optimal, but I feel for most cases it is the best option.
Let me know what you think, perhaps I've not fully appreciated you concern.
Thanks
In a larger repository, the extension is slowed down by many
cvs status
calls to single files. Callingcvs status
on the root folder (or individual checked-out folders) yields the same output in a batched format and needs only one remote call instead of potentially thousands. Could the extension maybe use one call tocvs status
?