Bug#290531: cvs-buildpackage: Doesn't work when importing on a branch

[Thorsten Glaser]

tags 290531 + moreinfo
thanks

Hi,

cvs import now has an -X version, is that what you need?

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#290531: cvs-buildpackage: Doesn't work when importing on a branch

[Frank Küster]

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 " and "cvs
>>remove " 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

Bug#290531: cvs-buildpackage: Doesn't work when importing on a branch

[Steve McIntyre]

On Sat, Jan 15, 2005 at 06:27:38PM +0100, Frank Küster wrote:
>
>I looked closer at
>http://people.debian.org/~frank/cvs-upgrade_2.99.9.lg, and searched for
>trfonts.map, one of the files that got to the trunk wrongly:
>
>cvs import: Importing /cvs/tetex/tetex-base/metapost/config
>U tetex-base/metapost/config/mfmp.ini
>U tetex-base/metapost/config/mfmp.mp
>U tetex-base/metapost/config/mpost.mp
>U tetex-base/metapost/config/mpost.ini
>cvs import: Importing /cvs/tetex/tetex-base/metapost/support
>N tetex-base/metapost/support/trchars.adj
>N tetex-base/metapost/support/trfonts.map
>
>It seems as if the file added to the upstream tarball since the last
>version get onto the trunk?
>
>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 " and "cvs
>remove " 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

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


signature.asc
Description: Digital signature

Bug#290531: cvs-buildpackage: Doesn't work when importing on a branch

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> schrieb:

> reassign 290531 cvs
> thanks
>
>
>   From what you said, the only cvs-buildpackage command
>  you had was cvs-update, which is a glorified way of saying
>   cvs import -m'blah' tetex-base source-dist some-tag-that-we-use

I looked closer at
http://people.debian.org/~frank/cvs-upgrade_2.99.9.lg, and searched for
trfonts.map, one of the files that got to the trunk wrongly:

cvs import: Importing /cvs/tetex/tetex-base/metapost/config
U tetex-base/metapost/config/mfmp.ini
U tetex-base/metapost/config/mfmp.mp
U tetex-base/metapost/config/mpost.mp
U tetex-base/metapost/config/mpost.ini
cvs import: Importing /cvs/tetex/tetex-base/metapost/support
N tetex-base/metapost/support/trchars.adj
N tetex-base/metapost/support/trfonts.map

It seems as if the file added to the upstream tarball since the last
version get onto the trunk?

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 " and "cvs
remove " 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?

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

Bug#290531: cvs-buildpackage: Doesn't work when importing on a branch

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> schrieb:

> reassign 290531 cvs
> thanks

Note that is bug occurs on gluck which has woody's (?) version
installed:

hi  cvs   1.11.1p1debian-9woody Concurrent Versions System

According to the logs on people.debian.org, it seems to occur with files
that are new to the vendor branch and therefore also to the trunk:

cvs import: Importing /cvs/tetex/tetex-base/metapost/config
U tetex-base/metapost/config/mfmp.ini
U tetex-base/metapost/config/mfmp.mp
U tetex-base/metapost/config/mpost.mp
U tetex-base/metapost/config/mpost.ini
cvs import: Importing /cvs/tetex/tetex-base/metapost/support
N tetex-base/metapost/support/trchars.adj
N tetex-base/metapost/support/trfonts.map

and the last two files are an example of files that got into HEAD. 

Regards, Frank


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

Bug#290531: cvs-buildpackage: Doesn't work when importing on a branch

[Manoj Srivastava]

reassign 290531 cvs
thanks

On Fri, 14 Jan 2005 18:31:50 +0100, Frank Küster <[EMAIL PROTECTED]> said: 

> This might be in fact a bug in CVS, hence the copy to
> [EMAIL PROTECTED]

Indeed.

> When I use the cvs-buildpackage and the CVS commands proposed by it
> to import a new upstream version in the vendor branch, and then to
> merge the upstream changes not to the trunk, but only to the
> experimental branch, some of the new files end up in HEAD
> nevertheless.

From what you said, the only cvs-buildpackage command
 you had was cvs-update, which is a glorified way of saying
  cvs import -m'blah' tetex-base source-dist some-tag-that-we-use

If CVS is not doing what you think it should,m then CVS needs
 to address that.

manoj
-- 
There is no grief which time does not lessen and soften.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C