![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
More I in an IDE
Feb. 24th, 2009 10:02 amSparked by some comments by ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
sml, I return to an idea that's been bouncing around in my head: an IDE that truly integrated with source control. It's useful that many modern IDEs help you with checking projects in and out, but mostly they're just taking the place of some other SCM client. There are three ways in which I think an IDE can leverage its specific position to help a tremendous amount with source control, mostly focused on merging - which is the part of SCM that causes most of us the most headaches anyway.
First and most significant, the static analysis tools (up to and including the compiler) an IDE has give it a vastly more informed picture of code changes than any pure-text merge system can hope for. When doing a merge, your IDE could reasonably look at not just the proximity of changes within a file, but the referential impact of the changes. This means it can both declare changes not to be in conflict when they, say, make adjacent changes to different variables, and also declare changes to be in conflict when they break references across multiple files, e.g. I change a method signature and all known invocations, while you add code that invokes that method with the old signature.
What's more, if there is genuine ambiguity about how changes should be merged, the IDE can inform its guesses about the correct result by checking which results are syntactically correct. It can even test build different merges. Of course, since this is relatively Smart behavior making guesses about your code, I think it should fall back ultimately on your judgement - but by doing all this checking upfront, the IDE can at least present much better guesses, and mark them with varying degrees of confidence. For instance, a rollup of merged sections could color code them from green (for changes which appear to be orthogonal to all other known changes) to red (for changes that cannot be satisfactorily merged automatically), with a spectrum in between (e.g. a yellowish marking might show up where two people separately add parameters to a function that appear to be entirely separate changes).
Second, by subscribing to updates on the relevant files/projects (most SCMs provide some sort of at least rudimentary mechanism to allow this), the IDE can speculatively pull in changes in the background, and apply the same intelligent comparisons to give the developer some notice of when they're making changes to pieces of code that someone else is also working on. If it's as good at analyzing code patterns as some programs (Idea) are today, it might even be able tell you when someone else has already added code that looks like the code you're adding, saving you from fixing the same problem. From a UI standpoint, I see the desireable behavior as being intuitive hinting as to the change overlap, rather than anything distracting like alerts - thus perhaps something like using color-coding again to, say, mark the margins from white for untouched code gradually darkening as overlap increases.
Third, and probably most contriversially, the IDE can invisibly create individual branches for each developer. When you save your files, they get committed to your private branch, and when you Commit, they get pushed into the (relative*) trunk. The two advantages to this are that a) you get your work backed up someplace non-local, and b) other instances of the IDE can use your not-yet-complete changes for speculative merges, as above, by looking at automated branches in source control. That means you get an idea of when you're touching the same ground as someone else far in advance of the code being stable for a check-in. Of course, code that's only on a private branch probably gets less weight given to it than anything on the trunk, and especially if it doesn't build on its own. Still, this provides a gradation between completely collaborative work and fully parallel work, where your environment can help you peek at other changes and figure out which ones are relevant to what you're doing.
I can see resistance to each developer being on their own branch, both because it creates longer times between merges and because programmers don't want their partial work recorded in source control. The former I think is a non-issue here, because the entire point of branching would be to aid merging as early and often as possible. The latter is a more serious concern, and I'm not sure it can be easily addressed. Maybe, a la AccuRev**, you control when you check into your private branch and when you commit back to the trunk; that would give everyone a measure of control over what they were showing, while still allowing lookahead before a large batch of changes is totally ready for checkin.
* You might be working on a branch already, which I'm calling your relative trunk.
** AccuRev is bad in most important respects, but giving you two-stage checkins had the glimmer of a good idea in it.
sml, I return to an idea that's been bouncing around in my head: an IDE that truly integrated with source control. It's useful that many modern IDEs help you with checking projects in and out, but mostly they're just taking the place of some other SCM client. There are three ways in which I think an IDE can leverage its specific position to help a tremendous amount with source control, mostly focused on merging - which is the part of SCM that causes most of us the most headaches anyway.First and most significant, the static analysis tools (up to and including the compiler) an IDE has give it a vastly more informed picture of code changes than any pure-text merge system can hope for. When doing a merge, your IDE could reasonably look at not just the proximity of changes within a file, but the referential impact of the changes. This means it can both declare changes not to be in conflict when they, say, make adjacent changes to different variables, and also declare changes to be in conflict when they break references across multiple files, e.g. I change a method signature and all known invocations, while you add code that invokes that method with the old signature.
What's more, if there is genuine ambiguity about how changes should be merged, the IDE can inform its guesses about the correct result by checking which results are syntactically correct. It can even test build different merges. Of course, since this is relatively Smart behavior making guesses about your code, I think it should fall back ultimately on your judgement - but by doing all this checking upfront, the IDE can at least present much better guesses, and mark them with varying degrees of confidence. For instance, a rollup of merged sections could color code them from green (for changes which appear to be orthogonal to all other known changes) to red (for changes that cannot be satisfactorily merged automatically), with a spectrum in between (e.g. a yellowish marking might show up where two people separately add parameters to a function that appear to be entirely separate changes).
Second, by subscribing to updates on the relevant files/projects (most SCMs provide some sort of at least rudimentary mechanism to allow this), the IDE can speculatively pull in changes in the background, and apply the same intelligent comparisons to give the developer some notice of when they're making changes to pieces of code that someone else is also working on. If it's as good at analyzing code patterns as some programs (Idea) are today, it might even be able tell you when someone else has already added code that looks like the code you're adding, saving you from fixing the same problem. From a UI standpoint, I see the desireable behavior as being intuitive hinting as to the change overlap, rather than anything distracting like alerts - thus perhaps something like using color-coding again to, say, mark the margins from white for untouched code gradually darkening as overlap increases.
Third, and probably most contriversially, the IDE can invisibly create individual branches for each developer. When you save your files, they get committed to your private branch, and when you Commit, they get pushed into the (relative*) trunk. The two advantages to this are that a) you get your work backed up someplace non-local, and b) other instances of the IDE can use your not-yet-complete changes for speculative merges, as above, by looking at automated branches in source control. That means you get an idea of when you're touching the same ground as someone else far in advance of the code being stable for a check-in. Of course, code that's only on a private branch probably gets less weight given to it than anything on the trunk, and especially if it doesn't build on its own. Still, this provides a gradation between completely collaborative work and fully parallel work, where your environment can help you peek at other changes and figure out which ones are relevant to what you're doing.
I can see resistance to each developer being on their own branch, both because it creates longer times between merges and because programmers don't want their partial work recorded in source control. The former I think is a non-issue here, because the entire point of branching would be to aid merging as early and often as possible. The latter is a more serious concern, and I'm not sure it can be easily addressed. Maybe, a la AccuRev**, you control when you check into your private branch and when you commit back to the trunk; that would give everyone a measure of control over what they were showing, while still allowing lookahead before a large batch of changes is totally ready for checkin.
* You might be working on a branch already, which I'm calling your relative trunk.
** AccuRev is bad in most important respects, but giving you two-stage checkins had the glimmer of a good idea in it.
