Issue #37: JSON-RPC-API: updating repo attributes moves repos
Reported by: | Bernhard Weitzhofer |
State: | resolved |
Created on: | 2014-09-11 12:10 |
Updated on: | 2016-10-10 12:41 |
Description
when calling the JSON-RPC method update_repo
, repositories are specified via the parameter repoid
either by their numerical id or by their name. This name can be qualified by prefixed group names, separated by slashes.
Unfortunately, when doing so, the repo name seems to be interpreted first as a fully qualified repo name to identify the repo (analog to an absolute file system path), but when doing the update, it then seems to be interpreted like a relative path within the current group. This results in repositories changing their groups unintended.
Sample code to clarify:
import itertools import json import requests request_counter = itertools.count() def call(method, **kwargs): global request_counter id = 'request_%s' % request_counter.next() headers = {'content-type': 'application/json'} payload = { 'id': id, 'api_key': MY_API_KEY, 'method': method, 'args': kwargs, } response = requests.post(MY_URL, data=json.dumps(payload), headers=headers) data = response.json() assert data['id'] == id return data ''' >>> # we have no repos initially ... >>> call('get_repos') {u'error': None, u'id': u'request_0', u'result': []} >>> # ... and no repo groups >>> call('get_repo_groups') {u'error': None, u'id': u'request_1', u'result': []} >>> # create a single repo "bar", implicitly creating group "foo" as well >>> call('create_repo', repo_name='foo/bar', repo_type='hg', enable_downloads=False) {u'error': None, u'id': u'request_2', u'result': {u'msg': u'Created new repository `foo/bar`', u'success': True, u'task': None}} >>> # trying to update the repo moves the repo from foo/bar to foo/foo/bar >>> call('update_repo', repoid='foo/bar', enable_downloads=True) {u'error': None, u'id': u'request_3', u'result': {u'msg': u'updated repo ID:21 foo/foo/bar', u'repository': {u'clone_uri': None, u'created_on': u'2014-09-11T14:19:45.008', u'description': u'bar', u'enable_downloads': True, u'enable_locking': False, u'enable_statistics': True, u'fork_of': None, u'landing_rev': [u'rev', u'tip'], u'last_changeset': {u'author': u'', u'date': u'1970-01-01T01:00:00', u'message': u'', u'raw_id': u'0000000000000000000000000000000000000000', u'revision': -1, u'short_id': u'000000000000'}, u'locked_by': None, u'locked_date': None, u'owner': u'admin', u'private': True, u'repo_id': 21, u'repo_name': u'foo/foo/bar', u'repo_type': u'hg'}}} >>> # repo is now foo/foo/bar >>> call('get_repos') {u'error': None, u'id': u'request_4', u'result': [{u'clone_uri': None, u'created_on': u'2014-09-11T14:19:45.008', u'description': u'bar', u'enable_downloads': True, u'enable_locking': False, u'enable_statistics': True, u'fork_of': None, u'landing_rev': [u'rev', u'tip'], u'last_changeset': {u'author': u'', u'date': u'1970-01-01T01:00:00', u'message': u'', u'raw_id': u'0000000000000000000000000000000000000000', u'revision': -1, u'short_id': u'000000000000'}, u'locked_by': None, u'locked_date': None, u'owner': u'admin', u'private': True, u'repo_id': 21, u'repo_name': u'foo/foo/bar', u'repo_type': u'hg'}]} '''
Attachments
Comments
Comment by Bernhard Weitzhofer, on 2014-09-11 12:22
Comment by Mads Kiilerich, on 2014-09-18 14:52
It seems like you know Python. Please see if you can contribute a fix (and test) for this issue.
Comment by Bernhard Weitzhofer, on 2014-09-23 13:50
Yes, I'll have a look at it.
Comment by Udo Spallek, on 2016-03-21 14:36
Please review pull request #212 as fix for this issue.
Comment by Mads Kiilerich, on 2016-06-16 13:04
Fixed
Comment by Udo Spallek, on 2016-10-07 16:05
I don't see how this issue is resolved.
Comment by Mads Kiilerich, on 2016-10-07 23:17
What do you mean? What doesn't work for you?
Comment by Udo Spallek, on 2016-10-08 10:48
IMHO, this issue is marked as resolved but not fixed. It is needed to apply the patch from pull request #212 manually, at least in Version 0.3.2. So IMHO it is better to reopen the issue.
Comment by Mads Kiilerich, on 2016-10-08 11:39
Right - that is the eternal problem with issue trackers: should issues be marked as resolved when they are resolved in the repository or when the resolution is released.
Comment by Thomas De Schampheleire, on 2016-10-09 18:36
With more frequent releases, that question would not be that important. I think that for the stable branch, the trigger to release could be the resolution of issues. For example, when an issue has been fixed, there will be a release within max. 1 month delay.
Comment by Udo Spallek, on 2016-10-10 08:12
I would prefer to mark them as resolved, as soon they are done and the code is pushed to the repository.
But in this case, I can not find the code resolving the issue - even not in the default branch on tip revision: https://kallithea-scm.org/repos/kallithea/files/d3930bd0c14a81743c73c78e11ae703a3772512f/kallithea/model/db.py#L1222
So again: IMHO this issue is not resolved. It may be accidentally set to resolved.
Comment by Mads Kiilerich, on 2016-10-10 12:16
Comment by Udo Spallek, on 2016-10-10 12:41
Cool, thanks a lot for the pointer of the resolution, which looks even better than my approach on tinkering with its symptoms. We will try to test the patch soon.
And I am sorry for the noise…