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).
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?
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.
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.
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.
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.
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.
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
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.
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).
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?
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.
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.
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.
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.
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
251fae0dDate: 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.
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
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