[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

Does the trunk still contain your bug-fixes?

On 16 Feb 2009, at 14:16, Rodney M. Bates wrote:

> I managed to get the trunk back to the original code, as I intended.
> The Tinderbox failure is undoubtedly a bug in the new stuff.  But it
> leaves me with more CVS questions, see below.
>
> Olaf Wagner wrote:
>> Quoting "Rodney M. Bates" <rodney.bates at wichita.edu>:
>>> Well, I can work on compilers, debuggers, and functional text  
>>> packages, but
>>> I can never operate CVS correctly.
>>>
>>> As far as I can tell, I think I got these checkins done in the  
>>> trunk, rather
>>> than the branch I created for them.  I created a tag on the trunk,
>>> "devel_m3core_text_2009_02_13", then created a branch with tag
>>> "devel_m3core_text_newtext_branch".  Apparently I got that much  
>>> right.
>>>
>>> But I am not sure whether the changed files went into the branch.   
>>> My
>>> CVS book reads as if just a cvs tag -b ..., followed by a cvs commit
>>> will do the commits in the branch, but the commit message doesn't  
>>> look
>>> like that happened.
>>>
>>> Can anybody help me with:
>>> 1) What really happened?
>>> 2) How should I have done this?
>> You probably forgot to update your workspace to the branch:
>>  cvs up -r devel_m3core_text_newtext_branch
>
> This command is in the recipe in my book, but my book assumes you make
> a branch first, get a copy of the trunk code, edit that,  then commit.
> I had done the coding first, naively thinking I could just create a  
> branch
> when ready to commit it.  So I deliberately left this step out,  
> thinking
> (rightly, as it turned out) that it would overlay my work with the
> unmodified code.
>
> So today, I made safe copies in other directories of both versions and
> started trying to unravel things.  Sure enough, the update -r   
> promptly
> replaced my new code with the old.  I used a different machine to do
> updates, and quickly found I now had the new code in the trunk and the
> old code in the branch.
>
> And of course, update -A first overlaid the old code I had now put in
> my text directory with what is in the repository trunk (the modified
> code), before clearing the sticky tag.
>
> By going through procedures doing CVS commands, interspersed with  
> copying
> versions of the code from my backup directories to the text  
> directory, I
> managed to get the trunk straightened out, (I think.)
>
> But it was convoluted.  To do any of this reasonably, I need a command
> that changes the sticky tag CVS considers me to be working on (like  
> the -r and
> -A options of update), but without the undesired side effect of also
> overlaying my local directory with what was in old tagged version,
> before changing the sticky tag.  Is there such a command?
>
> I will worry about the getting the new code into the branch tomorrow.
>
>> After that, the branch tag will be `sticky' in your workspace, until
>> you use cvs up -A, which clears it again (and transports you to the  
>> trunk).
>>> 3) How can I fix the damage?
>> Well, you can easily revert the changes on the main trunk by checking
>> out the latest version and using -j old-version -j current version,
>> and then commit it. This should put the old-version at the head of
>> the trunk again. Before you do that, you should probably commit  
>> everything
>> to the branch, thus you don't need to checkout your version again.
>> I think the version before yours was tagged devel_m3core_d2_4_0.
>> But perhaps it is not necessary to do this? Have tou had feedback
>> from others about the new sources? If nothing breaks and performance
>> gets better, I won't complain ;-)
>> Thanks for all the work,
>> Olaf
>>> PS: I believe that if you use the new files  with no additional  
>>> action,
>>> that you
>>> will get the same behavior as before, except that there will be  
>>> considerable
>>> constant-time slowdown due to lots of instrumentation and dynamic  
>>> deciding to
>>> use the original algorithms.  But I have not tested this.
>> So probably some improvements are needed before a release.