Sparked by some comments by [livejournal.com profile] 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.
First week finished. Have environment *mostly* set up. Tired. Still sick, but rather better. Have been getting acceptable amounts of sleep.

Now that I'm coding in the Windows world, and it is a very different world, I have been paying more attention to what technologies MS is cooking up. One of the things that's been getting buzz recently is LINQ, the Language INtegrated Query system,* a reasonable discussion of which can be found here. In short, it's embedding a thing kind of like SQL into an imperative language, working on more or less arbitrary data. I had heard vaguely about this, and I thought it sounded fairly interesting. You know, for a Microsoft project. And, since it's syntactic sugar for more typical constructions, I wondered whether someone had done anything like that in Perl, and if not why not. However, when I started thinking about how I would implement SQL queries in Perl, I ran into a number of troublesome issues, mostly involved with handling selection from multiple sources without a lot of cumbersome overhead in disambiguation. In a DB environment the rigid table definitions allow you to do that in a fairly non-ugly way, and it's still hidden SQL magic, so how you deal with it for unpredictable arbitrary data. Well, of course, the guys who put together LINQ must have come up with some solution, I figured, so I went and looked into it a little more.

So, it turns out they seem to only let you select from one source, and although it's implied I haven't seen any examples yet that select more than one element from that source. And, you know, if we're looking at
from x in FooCollection where x.size = 6 select x.name
which at any rate is going to be converted into
FooCollection.where(x => x.length == 6).select(x => x.name
then I might as well stick with
map {$_->name} (grep {$_->length == 6} @foo_collection)
I can't quite do the same thing in Java, but there's a well-established filtering pattern with iterators that comes to the same thing. I'm disappointed, but that's what I get for thinking Microsoft might have done something innovative.

*Which should be LIQ. People are so sloppy with acronyms. Then again, I'm in the acronyms-can't-be-compressed-in-other-acronyms camp, so from my perspective reform is rather a lost cause.

Profile

learnedax

November 2011

S M T W T F S
  12345
6789101112
13141516171819
20 212223242526
27282930   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 02:42 pm
Powered by Dreamwidth Studios