4 ms·
> accepted as being accurate and authoritative. > synonyms: recognized, authoritative, authorized, accepted, sanctioned That's what I meant for it to mean any
by Klathmon 8y ago
> accepted as being accurate and authoritative.
> synonyms: recognized, authoritative, authorized, accepted, sanctioned
That's what I meant for it to mean anyway...
- chrisweekly 8y agoIn software the "authoritative" aspect of the definition is crucial. How can two different endpoints both be authoritative? What happens if they differ?
- Klathmon 8y agoThen people will be confused, which is why I'm exploring options to ensure they stay in-sync.
- chrisweekly 8y agoI'd recommend simply designating one as master, one as slave. Why try to appoint two captains of one ship?
- Klathmon 8y agoBecause having one as master and one as slave is exactly the problem i'm trying to solve here. I want both to be master, so that users who are comfortable on both platforms are willing to make contributions to the codebase, so that any one service/system going down won't stop development, and so that as the "community" migrates around different platforms they can always find the full version of the software. Recommending simplifying a process to the point that it no longer solves the problem it's trying to solve isn't helpful.
- chrisweekly 8y agoSorry if my comments haven't been helpful. But I don't think the problem you're trying to solve is tractable. I'd be very interested to hear of a solution that doesn't rely on locking and is immune to conflicts. You might fake it (and meet your stated goals) by maintaining a true master behind the scenes and syncing to two public slaves... (ie, forks you treat as peers, each with a "master" branch) but that still leaves neither of them truly "canonical" -- a designation of authority that would apply to the place where you'd resolve conflicts given simultaneous commits.