Opened 19 years ago
Closed 19 years ago
#5014 closed defect (fixed)
vc api misses the sync() method
| Reported by: | Owned by: | Christian Boos | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.10.4 |
| Component: | version control | Version: | devel |
| Severity: | minor | Keywords: | cache sync |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Since r5114, trac/env.py calls Repository.sync(). The versioncontrol api in trac/versioncontrol/api.py however doesn't mention this method. It should document that call and provide a default implementation that raises a NotImplementedError.
Attachments (0)
Change History (13)
comment:1 by , 19 years ago
| Keywords: | cache sync added |
|---|---|
| Milestone: | 0.11 → 0.10.4 |
comment:2 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:3 by , 19 years ago
comment:4 by , 19 years ago
The new docstring in source:trunk/trac/versioncontrol/api.py isn't that clear. What is the purpose of the callback? And, I think it describes the situation from the wrong perspective. "If specified, feedback is a callback, taking a rev parameter, that should be called …", not?
But even then, it's not clear to me. The repository backend is called via sync(), and a feedback callback is given. Fine. Now, under what circumstances (or, more precisely, for which revisions) should the vc backend call that callback?
follow-up: 6 comment:5 by , 19 years ago
Well, the perspective is the one of the users of the API, not the one of the implementer of a subclass. I can try to give both perspectives.
Revised doc:
def sync(self, feedback=None): """Perform a sync of the repository cache, if relevant. If given, `feedback` must be a callback taking a `rev` parameter. The backend will call this function for each `rev` it decided to synchronize, once the synchronization changes are committed to the cache. """
comment:6 by , 19 years ago
Replying to cboos:
Well, the perspective is the one of the users of the API, not the one of the implementer of a subclass.
Oh, sure. My bad.
Revised doc:
This is clearer now.
comment:8 by , 19 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Shouldn't we have default implementations of pass for Repository.sync() and Repository.sync_changeset() (keeping the api changes minimal…)?
follow-up: 10 comment:9 by , 19 years ago
That's the case for sync() (well, the pass itself is actually missing, but since there's a docstring…) and I added a raise NotImplemented exception for
sync_changeset() (see comment:ticket:1892:11).
comment:10 by , 19 years ago
Replying to cboos:
Hm, I was even thinking about 0.11dev. Having a base class method without any implementation (not even raising a NotImplemented exception) doesn't seem to be good style.
follow-up: 12 comment:11 by , 19 years ago
Woops, I've just been hit by the #4100 issue, and no, I was using Firefox 2 and t.e.o is not using https ;-) I'll follow-up there.
Ok, let's write my comment again (making it shorter ;-) )
Sure, I'll add a "pass" for 0.11 and the NotImplemented for sync_changeset, and the s/feedback/rev_callback/ suggested by Matt, any other suggestion welcomed.
Note that the versioncontrol API will be revised a lot for 0.12 anyway, especially w.r.t. to the sync, which should become transparent to the plugin writer.
comment:12 by , 19 years ago
Replying to cboos:
Sure, I'll add a "pass" for 0.11 and the NotImplemented for sync_changeset, and the s/feedback/rev_callback/ suggested by Matt, any other suggestion welcomed.
Fine.
Note that the versioncontrol API will be revised a lot for 0.12 anyway, especially w.r.t. to the sync, which should become transparent to the plugin writer.
The main place to collect thoughts about that is VcRefactoring, I guess? It seems to me that the plan is to make all the caching transparent to the backend plugin. Note that for that to work, we'll have to support non-linear history graphs, which the current table(s) used for caching do not.
comment:13 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
API fixed in r5151.
Yes, VcRefactoring contains some ideas that are still valid for 0.12, I think.



Ah, I knew there was a good reason to put this
synccall in the CachedRepository constructor, initially. But it's better like it is now, as it is convenient in a number of cases to get the repository without trying to synchronize first.So yes, I'll add the
Repository.syncmethod, but I think a default implementation ofpassis better so that vc backend that don't use the cache will not have to bother.