You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a shared environment it's possible to have 2 people attempt to leave a comment on the same line of the same file.
To my knowledge there are no teams using this so fixing this is going to be low priority. Holler if you're using / want to use PC in a team environment.
Problem 1
There's a potential race condition here where person A leaves a comment, but person B has not yet received it, or has simply opened the file before the comment was added. There are a variety of reasons this could happen depending on how data is being shared.
In this scenario the PC server's repo is updated, but person B's plugin hasn't registered the change by the time they decide to leave a comment.
B leaves a comment, submits it to PC.
At this point i think PC will simply clobber person A's comment. I don't think there will be a conflict because it will probably just be considered an edit.
Problem 2
B makes their change, but then A's earlier commit is downloaded to B's system. We then have a merge conflict.
Solutions
I think the solution to Problem 2 is to have PC recognize that there's a merge conflict and take both changes. HOWEVER these will be conflicting JSON objects so data processing has to happen to make sure it remains valid JSON and that only the actual comment portion has both authors stuff in it.
I think the solution to Problem 1 is to check who the author is on the file we're about to replace ( "edit" ) and see if it's the same as the person who just submitted a comment. If they're the same just take the new one (as per usual). If they're different, merge the data, provide attribution.
In both cases the full comment should be returned to the submitter.
Side Effects
After submitting a comment the full comment must be returned to the submitter. The plugin should then show the contents of what came back, not what was submitted, because there may now be additional information. In practice they'll probably want to show what was submitted, until the response comes back and then replace it, although usually it'll be the same data.
The text was updated successfully, but these errors were encountered:
In a shared environment it's possible to have 2 people attempt to leave a comment on the same line of the same file.
To my knowledge there are no teams using this so fixing this is going to be low priority. Holler if you're using / want to use PC in a team environment.
Problem 1
There's a potential race condition here where person A leaves a comment, but person B has not yet received it, or has simply opened the file before the comment was added. There are a variety of reasons this could happen depending on how data is being shared.
In this scenario the PC server's repo is updated, but person B's plugin hasn't registered the change by the time they decide to leave a comment.
B leaves a comment, submits it to PC.
At this point i think PC will simply clobber person A's comment. I don't think there will be a conflict because it will probably just be considered an edit.
Problem 2
B makes their change, but then A's earlier commit is downloaded to B's system. We then have a merge conflict.
Solutions
I think the solution to Problem 2 is to have PC recognize that there's a merge conflict and take both changes. HOWEVER these will be conflicting JSON objects so data processing has to happen to make sure it remains valid JSON and that only the actual comment portion has both authors stuff in it.
I think the solution to Problem 1 is to check who the author is on the file we're about to replace ( "edit" ) and see if it's the same as the person who just submitted a comment. If they're the same just take the new one (as per usual). If they're different, merge the data, provide attribution.
In both cases the full comment should be returned to the submitter.
Side Effects
After submitting a comment the full comment must be returned to the submitter. The plugin should then show the contents of what came back, not what was submitted, because there may now be additional information. In practice they'll probably want to show what was submitted, until the response comes back and then replace it, although usually it'll be the same data.
The text was updated successfully, but these errors were encountered: