savetrio.blogg.se - P4merge competitors

#P4MERGE COMPETITORS UPDATE#
#P4MERGE COMPETITORS SOFTWARE#
#P4MERGE COMPETITORS SERIES#

Charles Simonyi’s (friend of ThoughtWorks) Intentional Software solves some of the same problems with a non-text, non CR-delimited ‘source’ concept. There is a sub-chapter of “programming” that is called Intentional. At least it would move the bar for what a conflict is.

#P4MERGE COMPETITORS UPDATE#

With a team wanting to refactor with impunity, and have merges work across branches (or as you frequently update working-copy in your local checkout), then having the source-control tool understand what you did and allow auto-merge through conflict resolutions is key. Merge-through-rename was the high-bar for the 2010 article, and it was referent to three-way merges that understood carriage-return delimited text really well. We want merges to be automatic and safe, and that’s more likely with smarter tools. Most of all “merge-through-rename”, but not only that. There are many others that are closer to our understanding of refactoring operations. Another example is “method reorder” where one method/function is moved below another.

#P4MERGE COMPETITORS SERIES#

Taking it further, a source-control tool at the top level, should also be able to understand “method rename” (and other refactorings), rather than a series of adds and deletes. I can’t count the number of times I’ve been screwed by an automated tool manipulating JS code”. And testing of Javascript applications is still not easy, so it’s a good example. In javascript you might never know unless you have very good testing. In java for example, it’s likely that a bad merge would be detected by at least a static check, even though it leaves a host of other possible issues. “The rise in usage of non statically-typed languages makes this even more imperative. Sure, some of the advanced diffing/merging tools like BeyondCompare, P4Merge, and Kdiff3 do a good job of this visualization, but it takes some effort to hook them into a source-control tool-chain, when the built-in merge technology should be as smart, but without having to prompt as much for human arbitration when there are conflicts. Add one element in a list, is a new line and a changed line (the comma). Diffs can be too noisy because the tools can’t give a break to specific languages. This is alluding to a level 6 on the SCMM. Things I’d like to see in the next generation of source-control tools Semantic diff/merge. Level -1 was reserved for tool that’s so bad that using nothing at all was preferable.

All history locally available, cheap local branching, merge-through-rename is smooth.

Faster again, merge-point-tracking better, merge-through-rename rudimentary.

Faster still + atomic commits, branching capabilities are decent, with merge-point-tracking.

Faster without atom commits, multi-user mode bearable.

Systems that remotely hold revisions safely, but really work best if they that remote server isn’t too far away, and staff don’t step on each other’s toes too much in terms of the same source files, while mostly avoiding branching because it is expensive, and everything is slow.

Summarizing the previously defined levels: It talks of where I’d like source-control to go, and reevaluates the article Lucas and I previously wrote. It was inspired by the Capability Maturity Model of course. I had been thinking of it for a many years (particularly the PVC Dimensions being level -1) and Lucas was a great collaborator to publish it, and crystalize the ideas.

Lucas Ward and I published a Source Control Maturity Model (SCMM) article nearly three years ago.