Steve McIntyre <[EMAIL PROTECTED]> wrote:

> On Sat, Jan 15, 2005 at 06:27:38PM +0100, Frank Küster wrote:
>>
>>I am not completely convinced that the bug is not in cvs-upgrade. In
>>older versions, there was a script cvs-co-upgrade (today it's still in
>>/usr/share/doc) that generated a list of "cvs add <file>" and "cvs
>>remove <file>" commands, to be applied to a checked out working copy.
>>
>>This script is no longer recommended - doesn't that mean that
>>cvs-upgrade now does something like this on itself?
>
> What does the output of cvs-upgrade look like in this situation? I
> must admit, I've never used cvs-buildpackage to know exactly how it
> works....

Well, the output of the current version is in the links I posted. The
output of the old cvs-co-upgrade script looked like this:

Version test passed
build_list /home/frank/tetex-bin/tetex-bin_2.0.2.orig.tar.gz > 
tetex-bin_2.0.2.orig.list.6872
build_list /home/frank/tetex-bin/tetex-bin_2.99.3.20041109-beta.orig.tar.gz > 
tetex-bin_2.99.3.20041109-beta.o
rig.list.6872
cvs add PROBLEMS-teTeX-2.0
cvs delete -fR config/ltconfig
cvs delete -fR config/ltmain.sh
cvs add fixes/flex-2.5.31-req-720976.patch
cvs add libs/gd/COPYING
cvs add libs/gd/Makefile.in
cvs add libs/gd/README.TXT

and the cvs commands are meant to be executed (I think the first three
lines went to stderr and where redirected into the logfile by me).

But after a look at the cvs-upgrade script I must say that Manoj seems
to be right: It does nothing but figure out versions to use for tag
names, unpack the source, do some sanity checks, change into the new
source dir and do

cvs $CVS_QUIET import ${importsubstmode} \
  -m"Imported upstream version $upstream_version. $changes" \
  "${cvsmodule}" source-dist "${cvs_upstream_tag}"

where $CVS_QUIET is either empty or -Q, and ${importsubstmode} is usuall
"-ko -d".

I'm not sure about the original purpose of cvs-co-upgrade, the relevant
changelog entry only says:

 * Since we fixed Bug#154365 in version 4.00, the watchdog script
    cvs-co-upgrade, has become unnecessary (since we do not miss files on
    upgrading, we do not need to check for missing files). 

and the referred bug was only a documentation bug; a problematic cvs
command line was recommended for merging the new upstream sources into
the workdir.

An example of a file added to the trunk while it should have been only
on the experimental branch is

http://cvs.debian.org/tetex-base/metapost/support/Attic/trfonts.map?graph=1.2&cvsroot=tetex&hideattic=0

Have I done anything wrong during the cvs upgrade -j.. -j..?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer


Reply via email to