Back to issue list Export

Currently Nitpick only supports one single database. This works fine as long as the intent is to use the bug tracker only on a single branch view at a time. Thus is a bug is entered in the trunk of a project, then it won't be visible in the branches until such time that the branch syncs with the trunk. This is likely alright for development, but causes problems when it comes to letting users or support people enter bugs. It is unlikely to be a sufficient reason to trigger a branch sync or merge just to receive updated issues. Instead Nitpick should have the ability to have multiple parallel databases. This would probably have to use functionality like svn:externals to have a second database appear in the branch, but actually be located in some central location (such as a support bug branch or the trunk).

travisb 2012-06-20 00:20:04
hash: 9b9b17873e124632990ccd7ca3de2ca1755bee6f2fe887f5f52186e36ca9d65b
Date: 2012-06-20 00:20:04
User: travisb

When it comes to parallel issues (ie. has a copy in the trunk and a copy in the current branch) these issues should perhaps be merged so that all the available comments appear. Since we have nested comments that is easy enough. The more difficult issue comes with merging the metadata of an issue. Perhaps we can use some sort of ghosting mechanism to show the state in all the non-current branches/databases?

travisb 2012-07-24 05:05:02
hash: 5b03ca8de3a4de72f6b49f460a13d8621e94bd89028ef5a276f537ec065aa3d5
Date: 2012-07-24 05:05:02
User: travisb

Comments should definitely be merged. But where should the new comments be put? I suppose that if the comment is for an issue in the primary repository that it should be placed in the current repository, even if the rest of the comments and issue exist only in a foreign repository. Orphan comments will have to be shown as parented by the issue if the foreign repository isn't there. Similarly local repository issues should have their metadata modified in the local repository.

travisb 2012-06-21 03:38:06
hash: 73edbd560e7aa9c96c6b78a0022bf9080dac1e34dc2de1f46921055e0891746f
Date: 2012-06-21 03:38:06
User: travisb

One thought on the implementation is for each Nitpick database to have a file which contains a project name and UUID. The UUID would be used to combine issues from different branches of the same project. So if you had a branch database and a trunk database as a parallel database then you would not see issues which are in both databases, but would instead see a combined/merged version. However, if you had a number of parallel databases from different projects then you would see which project they came from. This would be useful perhaps if you wanted to configure a Nitpick database to look over a number of subprojects. Say somebody uses Nitpick for each of their personal projects and wants to setup something so they can view all the bugs for all the projects from one spot.

travisb 2012-07-24 05:01:58
hash: 08655ba4dbc7c0ceb665d1871487eed6903e9b28771ce49c8c9c9ef2d03838a5
Date: 2012-07-24 05:01:58
User: travisb

A better implementation is to have a file with the repository UUID which is used to combine the repositories if they have the same UUID. Then there is a directory structure of foreign repositories where the directory name is the name to be used. This should provide ample flexibility and be able to handle the cases where branches and the trunk switch places often.

travisb 2012-07-03 21:01:35
hash: 7a61ffed998691c01fd306adcc054481e2378ae1383d2b8c54d986ef7c54529f
Date: 2012-07-03 21:01:35
User: travisb

An additional useful feature may be to allow adding comments and changing states of readonly subservient databases. Say if a project had an issue database and some distro also does and the maintainer uses the distro database as a subservient database. In this case the maintainer won't have write access to the distro database, but could still see and handle bugs locally. Then if they could place new comments or modifications into the appropriate directory and have them merged correctly locally then the distro database would get the comments and state changes when they caught up. This would allow comments from a branch on bugs created in the trunk to be made. Something similar would be to allow adding comments and changing state to issue repositories which are readonly and won't be merged. Like if a maintainer wanted to do a readonly import of issues from a distro bug tracker using different software.

travisb 2012-07-24 05:10:42
hash: 7280a2c5594a72214ccf44f47b03c858410e63b2cadee0ecaf8021b45860d285
Date: 2012-07-24 05:10:42
User: travisb

I've decided to leave this subfeature for a later release, if ever. It's now issue 251fae0d

travisb 2012-07-25 05:39:51
hash: 9a0db8b6ac1c9782b42ba11f24db54291ebf3dd6ae5e950dfdd237199c820b33
Date: 2012-07-25 05:39:51
User: travisb

I've gotten a basic implementation complete. Issues are collated across multiple repositories. I've renamed this feature 'Foreign Projects'. I believe I've got a last wins for Issue metadata. What's left to do are collating comments across repositories when displaying an issue and checking on commit support.

travisb 2012-07-25 06:06:08
hash: 50f360e71184072f9b8f0110909ab8726362310b49b246f89ae6b44424c7adfb
Date: 2012-07-25 06:06:08
User: travisb

Additional work includes: - Handling issues which have been deleted across repository clones - Combining all the filterable lists from the various projects so they can all be filtered upon

travisb 2012-07-25 23:16:17
hash: 004906deebe4d3f811c16c80f78ccb3f737b35b7f4f3e6392bb336ad61835332
Date: 2012-07-25 23:16:17
User: travisb

This feature required adding a uuid to the repository. The following short script can be run inside the .nitpick directory to create the necessary uuid file. #!/usr/bin/env python2.7 import uuid uuid_file = open('uuid', 'w') uuid_file.write(uuid.uuid4().hex) uuid_file.close() Once the uuid file has been created you must add and commit it to the VCS manually.


Tracked by Nitpick