3 ms·
I was thinking about merge conflicts in the context of Rust recently. In a way, the borrow checker would prevent any merge conflicts, because two people won't e
by Zababa 5y ago
I was thinking about merge conflicts in the context of Rust recently. In a way, the borrow checker would prevent any merge conflicts, because two people won't edit the same file at the same time. But this would require a central authority to give you permissions on a file to edit it for a certain duration, during which nobody else can edit it.
More software engineering research is good, I feel like we are lacking in that area. However, this was only for public code and analysis of private (company) code is not mentioned in the directions for future work. Would there be a way to extract information about conflicts and conflict resolution without giving away important parts of your code? I know that deobfuscation and retroengineering are whole fields, so I think companies wouldn't take the risk. But if there is a way to extract only the git information, maybe that would be possible.
- shadowgovt 5y agoI've used a version control system that has this feature (Perforce, specifically). In principle, it's good. In practice, I think we found it to be more trouble than it's worth... Engineers go on break / vacation / get hit by a bus too often with the locks held, and then there has to be a policy process to break the lock while that user still has outstanding changes that are now stale (in an entire environment that didn't reconcile "stale" code well because it was designed to prevent the need to merge code). At our scale, this required us to have someone act as a full-time "repo guru," which was a brutally thankless job.