cvs fumbles with packages and distfiles

Discussion:

Richard PALO

2014-10-02 08:58:08 UTC

cvs update: ignoring distfiles (CVS/Repository missing)
cvs update: ignoring packages (CVS/Repository missing)
cvs update: move away `distfiles/.cvsignore'; it is in the way
C distfiles/.cvsignore
cvs update: move away `packages/.cvsignore'; it is in the way
C packages/.cvsignore

is there any particular reason to keep these in the tree?
This foils a private ~/.cvsignore with packages and distfiles in it.

Joerg Sonnenberger

2014-10-02 09:57:48 UTC

Permalink

Post by Richard PALO

is there any particular reason to keep these in the tree?
This foils a private ~/.cvsignore with packages and distfiles in it.

Yes, they are the default location and as such, removing them would
create noise for most users. You know that you can easily just move the
location via mk.env?

Joerg

Richard PALO

2014-10-02 10:26:02 UTC

Permalink

Post by Joerg Sonnenberger

Post by Richard PALO

is there any particular reason to keep these in the tree?
This foils a private ~/.cvsignore with packages and distfiles in it.

Yes, they are the default location and as such, removing them would
create noise for most users. You know that you can easily just move the
location via mk.env?
Joerg

I didn't know about mk.env, but I do have the following in mk.conf

Post by Joerg Sonnenberger
.if exists(${PKGSRCDIR}/CVS/Tag)
PKGSRC_BRANCH!= ${TOOLS_PLATFORM.awk} -F- '{print $$2}' < ${PKGSRCDIR}/CVS/Tag
.else
PKGSRC_BRANCH= current
.endif
PACKAGES= /export/pub/pkgsrc/packages/${PKGSRC_BRANCH}/${MACHINE_PLATFORM}
DISTDIR= /export/pub/pkgsrc/distfiles

Regardless, the 'noise' is identical... every cvs update, I have to
remove the two .cvsignore files, as they are 'in the way'. It would be
nice to avoid that.

Since the pkgsrc infrastructure will create the directories when needed
(fetching or packaging) it appears unnecessary to keep them 'in-tree'.

Joerg Sonnenberger

2014-10-02 10:52:52 UTC

Permalink

Post by Richard PALO
Regardless, the 'noise' is identical... every cvs update, I have to
remove the two .cvsignore files, as they are 'in the way'. It would
be nice to avoid that.

Move them *outside* the tree if you care.

Joerg

Joerg Sonnenberger

2014-10-02 11:20:32 UTC

Permalink

Post by Joerg Sonnenberger

Post by Richard PALO
Regardless, the 'noise' is identical... every cvs update, I have to
remove the two .cvsignore files, as they are 'in the way'. It would
be nice to avoid that.

Move them *outside* the tree if you care.
Joerg

I guess I don't follow you Joerg. If you a referring to my
organisation, packages and distfiles are in /export/pub/pkgsrc
whereas PKGSRCDIR is in $HOME/src/pkgsrc. They are definitely
out-of-tree.

Post by Joerg Sonnenberger
cvs update: ignoring distfiles (CVS/Repository missing)
cvs update: ignoring packages (CVS/Repository missing)
cvs update: move away `distfiles/.cvsignore'; it is in the way
C distfiles/.cvsignore
cvs update: move away `packages/.cvsignore'; it is in the way
C packages/.cvsignore

cvs complains about the .cvsignore files which are currently checked
in and committed to *in-tree*.

Whatever you are doing does not apply to other people. It is a local
configuration issue. I have mostly seen it when cvs believes that
distfiles and packages should be under its control but got replaced.
Removing them from CVS/Entries might help.

Joerg

Richard PALO

2014-10-02 12:09:02 UTC

Permalink

Post by Joerg Sonnenberger
Whatever you are doing does not apply to other people. It is a local
configuration issue. I have mostly seen it when cvs believes that
distfiles and packages should be under its control but got replaced.
Removing them from CVS/Entries might help.
Joerg

Well, this never used to happen. Seems only since the last few months...

I tried your suggestion, first removed the directories distfiles and
packages, then removed their entries from pkgsrc/CVS/Entries and even
added packages and distfiles to my ~/.cvsignore.

I still get the problem after update, naturally the upstream committed

Post by Joerg Sonnenberger
U distfiles/.cvsignore
U packages/.cvsignore

Perhaps this is a [platform specific] regression since ??

Thomas Klausner

2014-10-02 13:19:18 UTC

Permalink

I still get the problem after update, naturally the upstream committed files

Post by Joerg Sonnenberger
U distfiles/.cvsignore
U packages/.cvsignore

Perhaps this is a [platform specific] regression since ??

This is correct behaviour. Why is this a problem for you? (You said
your distfiles and packages are somewhere else anyway, so why do you
care about these files?)
Thomas

Richard PALO

2014-10-02 11:09:31 UTC

Permalink

Post by Joerg Sonnenberger

Post by Richard PALO
Regardless, the 'noise' is identical... every cvs update, I have to
remove the two .cvsignore files, as they are 'in the way'. It would
be nice to avoid that.

Move them *outside* the tree if you care.
Joerg

I guess I don't follow you Joerg. If you a referring to my
organisation, packages and distfiles are in /export/pub/pkgsrc whereas
PKGSRCDIR is in $HOME/src/pkgsrc. They are definitely out-of-tree.

cvs complains about the .cvsignore files which are currently checked in
and committed to *in-tree*.

Martin Husemann

2014-10-02 11:53:49 UTC

Permalink

Post by Richard PALO
cvs complains about the .cvsignore files which are currently checked in
and committed to *in-tree*.

Yes, they are, but cvs does not complain about the for others.

Martin

Thomas Klausner

2014-10-02 12:18:28 UTC

Permalink

Post by Joerg Sonnenberger

Post by Richard PALO
Regardless, the 'noise' is identical... every cvs update, I have to
remove the two .cvsignore files, as they are 'in the way'. It would
be nice to avoid that.

Move them *outside* the tree if you care.
Joerg

I guess I don't follow you Joerg. If you a referring to my organisation,
packages and distfiles are in /export/pub/pkgsrc whereas PKGSRCDIR is in
$HOME/src/pkgsrc. They are definitely out-of-tree.

Post by Joerg Sonnenberger
cvs update: ignoring distfiles (CVS/Repository missing)
cvs update: ignoring packages (CVS/Repository missing)

Here's what's wrong. You do have distfiles and packages directories in
pkgsrc/ but they do not contain the proper CVS files, even though they
are still mentioned in pkgsrc/CVS/Entries.

Since you say that your distfiles are somewhere else anyway, just do:
cd /home/richard/src/pkgsrc && rm -rf distfiles packages && cvs up distfiles packages
and you should be fine.
Thomas

Thomas Klausner

2014-10-02 13:45:42 UTC

Permalink

Hi Richard!

Glad you could fix this.

On the other hand, I don't know yet how to tell git to ignore everything
*but* CVS and .cvsignore in the distfiles and packages directories, but I
guess that isn't too pressing since they're now out-of-tree (they weren't
when I set it up).

I think if you manually 'git add' files, they override the .gitignore
patterns.
Thomas

Richard PALO

2014-10-02 12:51:05 UTC

Permalink

Post by Thomas Klausner
Here's what's wrong. You do have distfiles and packages directories in
pkgsrc/ but they do not contain the proper CVS files, even though they
are still mentioned in pkgsrc/CVS/Entries.
cd /home/richard/src/pkgsrc && rm -rf distfiles packages && cvs up distfiles packages
and you should be fine.
Thomas

Indeed, since very long while now I have .cvsignore distfiles and
packages in my .gitignore which has always worked fine until recently.

The problem only manifests itself after having checked out a local
branch prior to checking out back to master in order to sync to current.

I removed these and now there is no longer this issue.

On the other hand, I don't know yet how to tell git to ignore everything
*but* CVS and .cvsignore in the distfiles and packages directories, but
I guess that isn't too pressing since they're now out-of-tree (they
weren't when I set it up).

Go figure... guess I'm sorry for the noise (even if distfiles and
packages in-tree are rather extraneous).

David Holland

2014-10-03 16:40:37 UTC

Permalink

I am inclined to think these .cvsignore files should go away,
nonetheless; it doesn't serve any purpose to have CVS knowing about
these dirs and it does occasionally cause complications.

--
David A. Holland
***@netbsd.org