[M3devel] [M3commit] CVS Update: cm3

[Rodney M. Bates]

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.