[galaxyLogic]

I think there is something wrong with the basic idea of git and similar systems, which is that anybody can just change anything because they work in parallel meaning changes they make can conflict. Therefore we have conflict resolution, but shouldn't we try to make it less likely for conflicts to arise in the first place?

Instead I think we need module-ownership and tools supporting that. At any given time every module should be assigned to an owner-programmer or small owner-team. Only they can change their modules. Others can request changes, or create their own copy of that module to modify, but not modify code owned by someone else willy-nilly.

If programmers cannot modify modules owned by others there will be no merge-conflicts, right?

I wonder why this kind of code-ownership approach isn't more widely practiced and why there doesn't seem to be much tool-support for it?

[xenomachina]

In the 90s, pretty much everywhere I worked used a locking source control system, where you'd have to lock a file before you could edit it. This meant no merge conflicts, but it did mean that you had to work quickly if you wanted to make changes to a file that was frequently edited.

[sam_lowry_]

ClearCase had elaborate rules to define ownership and permissions. I guess this feature creep was imposed by marketing the product to lawyers and paralegal first.

Ever ClearCase install I know of is an awful legacy system superseded in practice by git, even in environments that work on the need-to-know basis.

Lawyers and paralegal just ditched version control altogether, surviving on Office365 document sharing and distributed editing.

[albertopv]

So, back to Visual SourceSafe?

[galaxyLogic]

My experience with VSS was pretty good but I'm thinking of something more radical. VSS etc. allow you to temporarily lock a file so no-one else can edit it while you have it locked out. I'm thinking that instead of temporary lock-outs we should have persistent module ownership. Only the owners can modify the code of their modules, and perhaps temporarily grant commit-rights for their module to others. Preferably the owner should have a deputy or two who would take over if the owner gets sick.

Super-user can grant and take away ownership to any module. Super-user should have a deputy or two as well.

Here's the metaphor: In New York City and all cities you have traffic lights and there are parking rules, and pedestrian crossings and bike-lanes and some streets are one-directional. What would happen if all the rules and traffic-lights were taken out? You could still get from A to B, but probably on average much slower because you would get stuck in traffic-jams much more often.

Perhaps counter-intuitively creating rules which restrict how you can drive and park your car do not make you move slower, they make traffic more efficient. Traffic jam is like a merge-conflict. Two cars merging on to the same narrow street from opposite directions. One of them has to back out. And then so do all cars behind it. Not fun.

Git etc. are a bit like city without traffic lights, one-directional streets and parking restrictions. Anybody can do whatever they want, branch and branch and merge and resolve conflicts. It gives you the impression of great flexibility and freedom, but so would a city without traffic rules. Yet all cities have realized they need to restrict what people do on their streets, to eliminate "traffic-merge-conflicts".

Now naturally you can say that your project has rules in place as to who can modify what code and when (do you?). But I think there should be tool-support for that and persistent module-ownership instead of "module communism" where everybody owns everything. When everybody owns everything no-one is responsible.

I'm not a big rules-guy but I think traffic lights do more good than bad.