<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>- version control.  Activity Sharing (see below) only really covers the
<br>Pair Programming use case.  The version control concept covers a range<br>of other issues.  Develop should track changes made by programmers, and<br>provide them with a means to share and merge their changes. This one I
<br>spent a fair amount of time on.  The current version of Develop uses bzr<br>for version control, and it actually works in a very minimal way (or<br>did, anyway).  However, by doing so I was duplicating logic; in my view
<br>the correct approach would be to truly use DataStore/Yellow as our<br>storage mechanism.  However, the DS isn't a true source code management<br>system with merging and distributed history.  The models just don't
<br>*quite* fit.<br></blockquote><div><br>I'd love to pick your brains on this. As I look at the same issues, I see it as doubtful that the Datastore back-end will ever be a good fit, although the interface may work. On the back-end, I envision Develop as going beyond Pippy, to allow multiple-file projects; yet even an ideal and complete Yellow would probably only work for single files. On the front-end, the current Yellow interface does not appear version-aware, but I expect that will change, and I can easily see the interface being a good fit once it does. So you'd use Yellow just to store chits which index a revision in Bazaar, and Yellow would do all the VC interface based on its copy of the version history metadata. 
<br><br>Of course, a discussion of scope is appropriate at this stage. Should I scale back my plans, should this be a standalone activity, or should some of these functions be moved into the list of commonly-available sugar libraries? As a standalone, this would shape up to be a heavyweight activity, if it included Bazaar and IDLE (yes, I still favor building good collaborative editing into IDLE later, over building good source editing into AbiWord's flawed data model.) and my plans for Bityi (translating editor, see the wiki page). Moreover, some of these services would be appropriate for inclusion in other apps - Bazaar has some functions which would be good for Yellow or anything else which is doing non-real-time collaboration, and Bityi's translation would probably be appropriate (eventually) for any of the programming activities, or even any other kind of activity with a quasi-natural-language programming and/or logfile component. 
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>- Pippy and Develop should be worked on in concert.  Right now Pippy<br>just uses gtksourceview, and really should end up sharing a lot of
<br>common logic.</blockquote><div><br>This is exactly the kind of thing  I mean.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I think it might be appropriate to start over, and merely use the<br>current version as a reference.<br></blockquote><div><br>The best reference is in your head, not in the code. When can we talk again? (reply off-list)<br>
<br>Jameson<br></div></div><br>