Should the data be held in a separate file in the repository?
I'm thinking this might lead to issues where you have to manually merge a machine-generated JSON file, which (besides being no fun) could create problems.
An alternative could be some kind of human-readable (markdown/YAML) issue object embedded in block-comments inside the source-files? If you remove one of these files, for example, any issues pertaining to that file are removed with it.
Waking up this morning, I just thought of building into the issue tracker tool the ability to handle conflict resolutions, so you wouldn't have to do that manually; the interface would prompt you.
I don't dislike the idea of having the block-comments, but given that I (and my team) already comment heavily, that might turn into line noise very quickly.
The other issue, I believe, is that there are many scenarios where I will delete a file so I can start fresh, but I don't want to remove the 20-some-odd issues relating to it, since I'm refactoring.
Third, I typically use TODO annotation for self-reminders that don't quite warrant an issue, or else to remind myself EXACTLY where I left off during the previous coding session. They rarely stay in place for long.
However, perhaps we can use the Git hashes of files to create direct associations between files when necessary.
I do know that conflict resolution, however friendly we make it, will always be a potential issue. That said, I think it would usually show up only if two people are working in the same code territory, which we try to avoid in active teams anyhow. This could almost become an advantage in some cases, because any external modification to a task we were working on would not be able to escape our notice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Should the data be held in a separate file in the repository?
I'm thinking this might lead to issues where you have to manually merge a machine-generated JSON file, which (besides being no fun) could create problems.
An alternative could be some kind of human-readable (markdown/YAML) issue object embedded in block-comments inside the source-files? If you remove one of these files, for example, any issues pertaining to that file are removed with it.
Like some kind of
TODOannotation on steroids?Waking up this morning, I just thought of building into the issue tracker tool the ability to handle conflict resolutions, so you wouldn't have to do that manually; the interface would prompt you.
I don't dislike the idea of having the block-comments, but given that I (and my team) already comment heavily, that might turn into line noise very quickly.
The other issue, I believe, is that there are many scenarios where I will delete a file so I can start fresh, but I don't want to remove the 20-some-odd issues relating to it, since I'm refactoring.
Third, I typically use
TODOannotation for self-reminders that don't quite warrant an issue, or else to remind myself EXACTLY where I left off during the previous coding session. They rarely stay in place for long.However, perhaps we can use the Git hashes of files to create direct associations between files when necessary.
I do know that conflict resolution, however friendly we make it, will always be a potential issue. That said, I think it would usually show up only if two people are working in the same code territory, which we try to avoid in active teams anyhow. This could almost become an advantage in some cases, because any external modification to a task we were working on would not be able to escape our notice.