What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?
Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
a great VCS wouldn't require locking or pre-communication; it would simply refuse to even try to merge assets it couldn't deal with, and leave the result of a merge in a state where the user can reasonably address it (in this case, presumably just "yes, use mine" or "no, use the one already in the repo" and perhaps "use mine but rename it").
I don't get it. Now your options are to lose your work, or for somebody else to lose theirs, or, maybe an un-fun manual merge process - and this after you've both done the work! With a per-file lock, on the other hand, you can't start work until you've got the lock, which prevents others from starting work on that file in the meantime.
(It's usually possible to bypass the locking mechanism, but this is not a habit people get into, because the end result is the situation you describe, and nobody wants to end up there.)
We seem to be in some kind of local minimum here, but perhaps LLMs might help us escape it by facilitating the creation of more merge tools.
What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?
Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
a great VCS wouldn't require locking or pre-communication; it would simply refuse to even try to merge assets it couldn't deal with, and leave the result of a merge in a state where the user can reasonably address it (in this case, presumably just "yes, use mine" or "no, use the one already in the repo" and perhaps "use mine but rename it").
I don't get it. Now your options are to lose your work, or for somebody else to lose theirs, or, maybe an un-fun manual merge process - and this after you've both done the work! With a per-file lock, on the other hand, you can't start work until you've got the lock, which prevents others from starting work on that file in the meantime.
(It's usually possible to bypass the locking mechanism, but this is not a habit people get into, because the end result is the situation you describe, and nobody wants to end up there.)
We seem to be in some kind of local minimum here, but perhaps LLMs might help us escape it by facilitating the creation of more merge tools.