3 ms·

Does "semantic conflict" really have anything to do with VCS? It seems obvious to me that the same situation can happen during normal development on the head br

Does "semantic conflict" really have anything to do with VCS? It seems obvious to me that the same situation can happen during normal development on the head branch. A bit less obvious but still clear in my mind is that semantic conflicts can occur anytime a developer's assumptions about the code base are wrong. Yes, static typing fixes problems with changing function signatures but that's only the first step of the way. The next step is to start thinking about and defining modules (files, classes, whatever) in semantic terms. I haven't heard it discussed in a few years but the discussions around the Liskov substitution principle and Liskov/Wing semantic typing highlights the difficulties of adding semantics to everyday software development practices.

nandemo 15y ago
> Does "semantic conflict" really have anything to do with VCS? I think his point is precisely that VCSs cannot automatically avoid semantic conflict. He's not blaming the VCS, but rather saying that Feature Branch should be avoided even if you're using a modern VCS.
- div 15y ago
  The reason he is not fond of feature branches seems to be that they allow a single developer to work on a feature for too long before integrating with the master branch. This only becomes apparent in the footnotes where he states that if your feature branches live for only a day, then your basically doing what he calls continuous integration. This feels more like something that can be remedied through having good practices. Just like you shouldn't go without committing for days when working with Subversion, it is probably a good idea in a DVCS to: - integrate the main branch with your feature branch often (at least daily) - don't do semantic changes in a feature branch. Instead, switch to the main branch (or a very shortlived new branch) and do the semantic change. This should avoid 2 feature branches doing semantic changes and then having a merging hell after a week or so of development.

nandemo 15y ago

> Does "semantic conflict" really have anything to do with VCS? I think his point is precisely that VCSs cannot automatically avoid semantic conflict. He's not blaming the VCS, but rather saying that Feature Branch should be avoided even if you're using a modern VCS.

div 15y ago
The reason he is not fond of feature branches seems to be that they allow a single developer to work on a feature for too long before integrating with the master branch. This only becomes apparent in the footnotes where he states that if your feature branches live for only a day, then your basically doing what he calls continuous integration. This feels more like something that can be remedied through having good practices. Just like you shouldn't go without committing for days when working with Subversion, it is probably a good idea in a DVCS to: - integrate the main branch with your feature branch often (at least daily) - don't do semantic changes in a feature branch. Instead, switch to the main branch (or a very shortlived new branch) and do the semantic change. This should avoid 2 feature branches doing semantic changes and then having a merging hell after a week or so of development.