4 ms·
> Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue. Rule #1 of minimum viable programs is to solve the pr
by bachmeier 5y ago
> Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue.
Rule #1 of minimum viable programs is to solve the problems you have rather than as something (number of users in this case) goes to infinity. If you're working with software developers and they can't trivially resolve a merge conflict of this nature, perhaps they are not the best at their craft.
- alkonaut 5y agoThat's indeed true - but it does require some thinking ahead. You need to effectively commit and reserve the ID before you use it elsewhere. If you plan on writing two tickets where one references the other, you need to consider whether you should quickly reserve two ids then fill in the tickets, for example. Otherwise the conflict isn't trivial as you also have to resolve non-conflicted lines with textual references between the work items. A minimum viable product is of course possible to claim by constraining it further. No references between tickets! Just write a short note what you want and solve the problem with references when you come to it! A ticket system doesn't need cross references! I'd say it's definitely "minimum viable" (especially considering WHEN this was) but I wouldn't say a workitems-in-repo-with-races-for-ids will be a "do one thing well" situation. It's rather a "do one thing in the simplest way possible"