3 ms·

> This file was also checked into a global CVS archive that all project members had access to. Today one might use GIT or SVN but any revision control system wo

> This file was also checked into a global CVS archive that all project members had access to. Today one might use GIT or SVN but any revision control system would do. Having locally created sequential ID's seems...strange. Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue. There are tons of ways of resolving this (such as author-prefixed ids "joe-23"). But simply calling it ticket++ in a global shared directory seems it could become a source of frustration and honestly a pretty inelegant solution to the problem. He mentions "doing one thing and doing it well" and being a "minimum viable program". One could argue that doing ONE thing reasonably when it comes to creating database records, is allowing me to create one without a conflicting ID. If the new_ticket command is actually immediately creating the entry in the central repository, retrying until it successfully allocates the next ID, then it works I suppose.

tpoacher 5y ago
Having made a similar project (see comment above: https://news.ycombinator.com/item?id=29965597 https://news.ycombinator.com/item?id=29965597 ) there's a (predictable? unexpected?) benefit to keeping a numerical index. It forces the ticket opener to commit as soon as possible, or risk having to re-index their tickets due to conflicts. This means that in any multi-member project, it encourages users to first check that a similar/duplicate ticket has not already made it into the repository in the meantime, and commit their tickets and make them visible to all other users with an accompanyign commit (and any notification-hooks that this entails) as soon as possible. Obviously you could also have a commit hook which reindexes tickets automatically, yes, but the focus here is all about simplicity and hackability first - and I think a behavioural solution is probably better than an automated one in this case anyway.
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 ago
  That'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"

tpoacher 5y ago

Having made a similar project (see comment above: https://news.ycombinator.com/item?id=29965597 https://news.ycombinator.com/item?id=29965597 ) there's a (predictable? unexpected?) benefit to keeping a numerical index. It forces the ticket opener to commit as soon as possible, or risk having to re-index their tickets due to conflicts. This means that in any multi-member project, it encourages users to first check that a similar/duplicate ticket has not already made it into the repository in the meantime, and commit their tickets and make them visible to all other users with an accompanyign commit (and any notification-hooks that this entails) as soon as possible. Obviously you could also have a commit hook which reindexes tickets automatically, yes, but the focus here is all about simplicity and hackability first - and I think a behavioural solution is probably better than an automated one in this case anyway.

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 ago
That'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"