Re: Syncing packages to upstream one oh one.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> On Sun, 2003-02-09 at 02:17, Steve Youngs wrote:
>Yep, looks good. I generally do my syncing like this:
>
>1) diff -urNb xemacs-pkg-src/ upstream-src/ > initial-patch.diff
>
>I use that as a starting point and reference if I need it. I *don't*
>send 'initial-patch.diff' to xemacs-patches, it's only for my own
>personal use to aid in syncing.
VS> This is pretty much where I start too. Additionally, I try to arrange
VS> upstream-src/ so that the directory layout matches the XEmacs one before
VS> doing the diff.
Good point.
>From this point on, my process is somewhat similar to Steve's,
but I
VS> like to more work by hand, using the diff file generated above in
VS> diff-mode, I like it.
I'm not overly familiar with diff-mode (beyond the basics anyway).
Maybe I should get more acquainted with it.
VS> With removed ones, more care is needed since we package extra files in
VS> some packages (ie. ones that aren't present in the upstream pkg), eg.
VS> psgml-html.el in the PSGML package.
Yes, that is something you need to be aware of. Intimate knowledge of
the package you're synching helps here. :-)
VS> When I'm finished with the diff, or earlier from a "checkpoint", I
start
VS> test building the package, according to Steve's post (step 7 and the
VS> ones after it). One good addition to this list is to build the package
VS> "alone", eg:
VS> cd packages
VS> make distclean autoloads
VS> cd xemacs-packages/pkg-under-sync
VS> make install
VS> This is a good (and probably the only easy) way to catch missing
VS> indirect dependencies.
Yes. Another good point. I think I more or less implied this in my
previous post, but thanks very much for making it clearer, Ville.
>The resulting CVS buffer gives you a number of things that you
need to
>pay attention to:
>
>- "Up-to-date" files need to be 'cvs rm'd' because they
don't
>exist in the upstream-src/ These files may also need to be
>removed from the Makefile (ELCS), so at this point, fix the
>Makefile. Then "mark" these files in the CVS buffer by
>pressing 'm' on each one and then press 'r' to 'cvs rm'
>them. (type 'u' on these files to "unmark" them).
VS> I might be missing the context partially here because my process is
VS> somewhat different, but I smell potential danger here. It is possible
VS> that there are files that haven't had any changes between upstream
VS> releases and we have an equivalent version. Giving the general advice
VS> to 'cvs rm' those (ie. "Up-to-date" ones) gives me the
creeps...
I understand your concerns, but if you read my previous post again a
paragraph or so higher up you'll see how I do it. When I do the
cvs-update the only files in place are the upstream ones. So the
"Up-to-date" files are files that existed in the XEmacs package but
not in the upstream package.
And I'm comforted in the knowledge that it is (mostly) hard to shoot
yourself in the foot with CVS. You can always go back to a previous
version of any particular file.
>Any comments? Is anything blatantly wrong or did I leave
anything
>out? Ville, what do you think?
VS> Looks good to me, thanks! At the very least, providing archive
VS> links to these messages somewhere should be done.
Somewhere under "Developing XEmacs" on www.xemacs.org, and in Adrian's
~/.abbrev_defs for starters. :-P
VS> It would be great if someone could prepare a skeletal TeXinfo
VS> file based on this thread (TeX-illiterate-Ville here) and prepare
VS> it for addition into the general-docs package.
I could do it, but it would be a very long time before I could get to
it. Perhaps somebody else would like to run with this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|