[Texmacs-dev] Deconstructing TeXmacs (was: Applied patches for TeXmacs-1.0.1.14)

[David Allouche]

On Wed, May 21, 2003 at 06:28:11AM -0600, Nix N. Nix wrote:
> On Wed, 2003-05-21 at 04:26, David Allouche wrote:
> > I'll do this if Nix and I can actually cooperate on deconstructing
> > changes in rew releases of texmacs.
>
> By "deconstructing changes" do you mean "trying to figure out which
> patches Joris applied, in case he didn't mention anyting in any of the
> usual channels" ?

Actually, that is a bit more than that.

Generally, when a new release of texmacs come out I do the following
(the exact procedure is still being elaborated):

  1. Run a sript to rename the TeXmacs-$VERSION directory and change
     occurences of the literal version number inside source files.

  2. Figure out which files were moved and where (generally this step
     is empty, unless a reorganization is in progress).

     After this step, I can get a meaningful global diff of the source
     tree.

  3. Skim through the diffs to get a general idea of what happened.

  4. Check how patches were applied. I have automated tools which help
     me greatly there and tell me for each file if:

       -- it matches the the new version;

       -- it locally matches the new version (diff3 found no conflict);

       -- there is a merge conflict (some additional changes seem to
          have been done).

       -- the upstream file was not modified.

  5. Break the remaning changes in clean patches so they can be more
     easily understood and to provide clean patchsets to the revision
     control system.

     I also have an automated tool to help me there. But sometimes
     (e.g. 1.0.1.13) there are so many entangled changes I just give
     up on this step.

I have been doing this for some time using ad-hoc tools. I recently
switched the whole process over the arch revision control system. That
resulted in better tools and more reusable data.

The tools I am using at the moment are a collection of shell scripts
running on top of arch and the kdiff3 program to visualize the diff,
resolve conflicts and perform partial merges.

Each time I figure out an elementary modification I commit a revision
into the revision control system. Such elementary modifications are:

  -- application of a patch already in the revision control system,
     only in another branch;

  -- modifications over such a patch;

  -- application of an external patch plus additional modifications;

  -- logically independent original change (they are produced in step
     5 above).

This adds some significant value:

  -- better understanding of texmacs;

  -- a detailed changelog;

  -- "executable" change history allowing flexible merging of
     development branches with minimal conflicts.


> > What I would expect from Nix side would be to construct patchs which
> > show how his proposed patches where actually merged and add some
> > comments like "applied ok", "applied incorrectly, that feature is
> > missing there" or "applied incorrectly, bug introduced there".
>
> Aaaah - just like the extra fonts patch, where "mathscr" was left out.
> Yes, I suppose I could have commented on savannah, saying that the patch
> was applied incompletely.  I will do that from now on, instead of
> commenting here (on texmacs-dev).

Yes. I got into the habit of checking application of every patch. Now
that Joris actually uses the patch(1) utility there are much less
errors than there used to be. Nonetheless this is good practise, it
helps catch out a number of stupid bugs and it improves my knowledge
of texmacs.

Actually, what I do when I find such a mistake is to add a comment
"improperly applied, fix pending" on Savannah and keep the patch open.
When I have completed the deconstruction operation and merged in my
development branch I post a fix and close the previous patch.


> > Eventually, I hope we would be able to collaborate on release
> > deconstruction. I am not sure how that should be implemented though.
>
> Again, I'm sort of fuzzy on this whole "deconstruction" business - once
> again, I assume you mean "extrapolating the identity of the applied
> patches given the source for the new release".

I think I gave you an accurate picture of what I mean. If we can
collaborate on that work (specifically on the patch-checking step)
I'll give you administrative rights to the patch manager.

--
                                                            -- ddaa