Re: lilypond-mode.el Changelog AUTHORS.texi

[Juergen Reuter]

On Fri, 22 Nov 2002, Heikki Johannes Junes wrote:

>
> > > $ cvs diff -uN file1 file2 file3 ... > yourpatch.diff
>
> compares agains latest version, always.

Not quite.  The cvs man page says:

"If you don't specify a particular  revision, your  files  are  compared
with the revisions they were based on."

My preferred way to make a patch (roughly, with modifications as needed)
is:

1. Get the latest revision of each file.  For this purpose, check out the
   HEAD revision (if not already done) and run cvs update (i.e. retrieve
   the latest available revision).  Note that the set of the latest
   available revision of each file typically does not represent a release
   (such as 1.7.8), but mostly some kind of interim version.

2. (Re-)build lilypond.  If only a few things have changed since the last
   cvs update, "make all" may work; if in doubt, you should completely
   rebuild lilypond.  "make distclean" is a good way to enforce a
   complete rebuild, but it also removes some files such as the configure
   script, which you then also have to rebuild (i.e. by running
   autoconf/automake); alternatively, calling cvs update once again should
   retrieve the missing files.

3. Check if this interim version is basically working.  Interim versions
   are typically full of bugs, but you should check if it is in such a
   state that you can start working on it.  To check, you may e.g. try to
   compile some .ly files.  Actually, during build, some .ly files are
   already compiled.  So, if you can succcessfully build, that means that
   things basically should work.
   (In your particular case of working on the .el files, this check may
   be less important.)

4. Now it depends on what you are doing.  If you are not changing too
   many files, probably the best thing to do is to just ignore what's
   going on in the cvs repository; trying to keep always up with the
   newest versions while still working on your files is possibly a waste
   of time.  But this is my personal experience and may differ for other
   people or other circumstances (e.g. when touching many files).

5. Update to the latest revisions.  If your patch works, you should
   migrate to the latest revisions before posting it.  This is simply done
   by saying "cvs update".  But be careful: if someone else also worked on
   the same files, cvs will merge your modifications with those in the
   repository.  Often, such modifications occur at different places in
   the file such that they do not conflict.  However, if a conflict
   occurs, cvs will merge nevertheless, but will inform you about the
   conflict and mark the conflict in the merged file.  In the case of a
   conflict, you should go back to step 4 to solve the conflict.

6. Rebuild lilypond once again and check if your patch still works.  cvs
   detects conflicts on a syntactical basis, but it does not track
   semantic information such as change of variable names.  Hence, even if
   cvs does not report a merge conflict, a merged file still may not
   compile.  Therefore, rebuilding the whole thing and testing it is
   generally a good idea.  If it fails, go back to step 4.  (Once again,
   in your particular case of just changing .el files, this step may be
   overkill.)

7. Submit a patch.  Just go into the top level directory of lilypond
   and say something like "cvs diff -u > mypatch.diff".  (You may want
   to check the contents if the generated file afterwards.)  If I recall
   correctly, Han-Wen once said that he prefers the ChangeLog entry to be
   posted separately.  I think this is because cvs typically will create
   merge conflicts on the ChangeLog file, such that it is much easier for
   Han-Wen to put it in separately rather than solving lots of cvs
   merge conflicts.

By the way, if you want to know which files are going to be merged
*before* you issue cvs update, just say "cvs status | grep Status".
(I am assuming here that during the short moment within the cvs status
and the cvs update command the repository does change.)  If you have very
complex changes that are going to be merged, then you may want to put a
copy of your file somewhere else before running cvs update.

Once again, this is my personally preferred way.  Other people may have
experienced cvs development differently.  Regarding the format of patches,
Han-Wen and Jan are the main developers and thus have the authority of
putting the "last word" upon this subject, since they have to integrate
all the patches into lilypond.

Greetings,
Juergen