[Idle-dev] idle-fork, cvs advice anyone?

[StephenM.Gava]

On Wed, 27 Jun 2001 12:44am, Kurt B. Kaiser wrote:
> Stephen M. Gava <elguavas@users.sourceforge.net> writes:
> > By all means if you can think of the simplest structure and how to get
> > there to acheive this aim please do so, it would be a great help I think
> > especially
>
> Stephen,
>
> After sleeping on it, here's my thinking:
>
> I make the assumption we are starting with the VPython version of IDLE,
> merging recent changes from Python IDLE, and continuing development through
> changes at IDLE-fork plus occasional patches from Python IDLE
>
> CVS appears to "use up" the default 1.1.1 vendor branch during any initial
> import; the canonical vendortag is the username and the releasetag is
> "start". In the case of VPython IDLE, it appears the vendortag was
> "avendor" and the releasetag was "arelease".
>
> If VPython IDLE was still being developed then we would want to merge its
> updates also, but it doesn't seem that that is a consideration. (If it
> were, the new release could be imported again on the "avendor" branch.)
>
> For simplicity, assume that the changes you made are backed out. Then one
> approach is to have the IDLE-fork trunk and two vendor branches, VPython
> IDLE and Python IDLE. Development would proceed along the trunk, with
> occasional merges from the vendor branches. No other branches seem
> necessary at this time.

The Vpython vendor branch is not required to be ongoing. Vpython should have 
been imported and merged once with python-idle at the beginning to give the 
ongoing idlefork trunk. From then on the only external merging required into 
idlefork should be occasional minor ones from python-idle. 

The only other major initial external change to idlefork will probably be 
Guido's own "external process execution" work which will likely come to me as 
a patch and may require the removal of, or merging with, David Scherer's 
implementation of this feature.   

> In the case of the VPython branch, there is probably going to be only the
> one merge of what we have, but I suspect it will have to be done explicitly
> to get the file HEADs off the branch and onto the trunk so they can be
> merged with the other (Python) vendor branch: update -A and then update -j
> arelease.
>
> As far as the Python IDLE branch goes, what we are interested in is the
> changes since VPython IDLE forked. It looks like the idle05 tag in the
> Python CVS was established June 11, 1999. Maybe Dave Scherer remembers the
> DATE he downloaded, it might be later than that.  What I would suggest is
> to export a version of Python IDLE as of midnight GMT of DATE - 1. Import
> this into branch 1.1.3 with python-cvs vendortag and a releasetag something
> like python-cvs-fork.
>
> Next, export the current version of Python IDLE and import it into the same
> 1.1.3 python-cvs vendor branch with releasetag something like
> update-20010626. The diffs can be checked out into a local directory via
> checkout -j python-cvs-fork -j update-20010626 and reviewed individually.
> Some of them may conflict conceptually with IDLE-fork.
>
> The merge of acceptable diffs can be accomplished by update -A and
>      update -j python-cvs-fork -j update-20010626 filename
>
> I assume the gurus on the list will double check all this and identify any
> misconceptions or improvements!

I think this ends up pretty much equalling in results the process I set out 
conceptually to follow, but as I mentionned I got stuffed up by not importing 
python IDLE into 1.1.3 (as you have it above) so it took over the default 
vendor branch where Vpython was. 

Apart from any possible corrections by any helpful listening gurus (Anyone??) 
do you feel confident to follow the steps you've outlined (starting with 
reverting my earlier attempt), and to complete the initial setup, up to the 
stage where the diffs on the final merge are ready to be reviewed?
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon