Re: sync auctex 11.84: good news.
BTW, I forgot to say before: "Congratulations and thanks!" to you and
Mats for persevering through this.
Uwe Brauer writes:
>>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Well I meant *build*, when I am running make.
Fine. Then the distributed packages are expected to run properly no
matter what the user's TeX installation looks like (as long as LaTeX
is on $PATH)?
>> cvs add newfile
>> cvs remove oldfile
> This is much preferable. Although CVS won't preserve history, when we
> move to a more capable version control system the migration script
> will see the remove/add pair and do the right thing. You can automate
> this with a shell function
> function cvs-move () {
> oldfile=$1
> newfile=$2
> mkdir -p `dirname $newfile`
> mv $oldfile $newfile
> cvs remove $oldfile
> cvs add $newfile
> cvs commit -m "Move $oldfile to $newfile." $oldfile $newfile
> }
Oops that is (t)csh?
No, that's Bourne shell. I don't use csh at all.
And what about
cvs remove:
find . \( -name '*' -o -name '.[a-z]*' \) -print -exec cvs remove {} \;
Or something of the sort and then after the copy the same for add
You need to do "something of the sort," I think. Specifically, cvs
wants you to rm the file before doing cvs remove. You need to
substitute "rm {} && cvs remove {}" for the simple "cvs remove
{}".
The most important thing is preserving the XEmacs meta-data (Makefile,
package-info-in), as David K points out. I was worried that (eg)
rm package-info.in
cvs remove package-info.in
cp ../new/package-info.in package-info.in
cvs add package-info.in
would disconnect the file's history, but actually if you cvs remove
then cvs add a file, the old file,v is recovered from the Attic, so
you don't lose any history (you just get the spurious cvs remove/add
pair, but that's no big deal).
Please do 'cvs tag' before and after this operation, though. That way
(a) if something really bad happens, you can recover pre-sync state,
and (b) post-sync diffs can be against something more or less similar
to current state.
Again oops looks again complicated.
Well, it's *your* XEmacs package. Do what makes sense for you. Just
do what you need to do, and coordinate with Norbert so that he can
make any recent packages before your change. Then we'll have a big
auctex-building party and deal with any issues that come up.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta