CVS sticky information ignored on import

2002-04-08 Thread Hamish Allan

Hi,

I'm a newcomer to CVS so please forgive me if the answer to this
question is obvious. I have tried to find an answer in the FAQs and
the Cederqvist but without success.

It seems to me that if a file is marked as binary or tagged in
CVS/Entries in a sandbox, e.g.:

/noodle.jpeg/1.1/Mon Apr 8 16:39:14 2002/-kb/TNOODLE_FINAL

when 'cvs import'ed to a new repository, the resulting version should
be tagged and registered as binary, so that when you 'cvs checkout' it
again the resulting sandbox has the same binary/tag information.

However! This doesn't happen for me. I am using a straight 'cvs
import' with no extra arguments, and a straight 'cvs checkout' to get
the file back. I think it's the import which is losing the
information, as the file 'noodle.jpeg,v' makes no reference to
'NOODLE_FINAL' and the line just before what seems to be the binary
contents of the file reads 'text'. Incidentally, this is also the case
if I explicitly try to import the file '-kb'.

Can anyone tell me what I'm doing wrong? I appreciate that I might be
able to get it to work by putting *.jpeg in my cvswrappers file but
I'd like to know whether I'm missing something fundamental.

thanks in advance,
Hamish
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: CVS sticky information ignored on import

2002-04-08 Thread Greg A. Woods

[ On , April 8, 2002 at 09:13:01 (-0700), Hamish Allan wrote: ]
> Subject: CVS sticky information ignored on import
>
> It seems to me that if a file is marked as binary or tagged in
> CVS/Entries in a sandbox, e.g.:
> 
> /noodle.jpeg/1.1/Mon Apr 8 16:39:14 2002/-kb/TNOODLE_FINAL
> 
> when 'cvs import'ed to a new repository, the resulting version should
> be tagged and registered as binary, so that when you 'cvs checkout' it
> again the resulting sandbox has the same binary/tag information.

'cvs import' does not "work" from within a working directory (aka
sandbox) -- i.e. it does not do anything special.

Or rather it only works by virtue of the fact that by default it'll
ignore all the administrative "CVS" sub-directories and the files they
contain.

Unless you're managing third-party sources you shouldn't use "cvs import".

If you're managing third-party sources that have been checked out from a
public CVS repository then you probably want to check them out from your
own local repository using 'cvs checkout -P -ko' (and 'cvs update -d -P
-ko' too of course).  On unix-ish platforms this will preserve even
binary files transparently (since there is no such thing as a "text"
file per se on Unix -- they're all 8-bit binary transparent) and all you
have to do is avoid keyword expansion, which you probably want to avoid
anyway if you're manaing third-party source code from a third party CVS
repository and thus which may already contain its own RCS keywords that
you do not want to disturb!

However if you're managing third-party binary files and checking them
out on non-unix-ish platforms then you will have to individually ensure
that the '-kb' flag is set in the RCS files in your own repository for
every binary file (but not for text files if you want proper text
handling to work!).

If you're doing the latter a lot then you might be better off using
something other than CVS.

-- 
Greg A. Woods

+1 416 218-0098;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Segmentation Fault (was Re: CVS sticky information ignored on import)

2002-04-09 Thread Hamish Allan

Thanks Greg.

> 'cvs import' does not "work" from within a working directory (aka
> sandbox) -- i.e. it does not do anything special.
> 
> Or rather it only works by virtue of the fact that by default it'll
> ignore all the administrative "CVS" sub-directories and the files they
> contain.

Ah, the tantalising 'by default'... I was hoping there would be some
way to persuade CVS to use the sticky data from the administrative
"CVS" sub-directories for the import. After all, the command does take
kflags and release tags as arguments!

I have ended up using the following instead:

find . -name Entries | xargs grep "/-kb/" \
  | sed -e "s|CVS/Entries:/||" -e "s|/[^/]*/[^/]*/-kb/.*||" \
  | xargs cvs -d $CVSROOT admin -kb

Actually that's not true, because if there are any files marked -kb in
the sandbox which are not imported because they're on the default CVS
ignore list, the admin command SIG_SEGVs.

Hence I've copied this to the gnu.cvs.bug list; if anyone is
interested, I can give you the exact script I'm running and the
sandbox source tree I'm running it on (which is
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.8/src/mozilla-source-0.9.8.tar.bz2
BTW).

For archive purposes, if anyone else is trying to do the same thing I
circumvented the segfault problem by creating an 'ignore' list from
the original import (| grep "^I " | grep -v "CVS$" >> $CVSIGNORELIST)
and then

for i in $(find . -name Entries | xargs grep "/-kb/" \
  | sed -e "s|CVS/Entries:/||" -e "s|/[^/]*/[^/]*/-kb/.*||");
  do grep $i $CVSIGNORELIST || cvs -d $CVSROOT admin -kb $i; done

If anyone can think of a better way to determine which files not to
admin (e.g., using an exit code from cvs to determine whether the file
is in the repository) I'd love to know.

thanks,
Hamish

p.s.
> Unless you're managing third-party sources you shouldn't use "cvs import".

Unfortunately that's what I'm doing!

> However if you're managing third-party binary files and checking them
> out on non-unix-ish platforms then you will have to individually ensure
> that the '-kb' flag is set in the RCS files in your own repository for
> every binary file (but not for text files if you want proper text
> handling to work!).

Unfortunately that's also what I'm doing!

> If you're doing the latter a lot then you might be better off using
> something other than CVS.

Well... mozilla uses CVS, and whatever I used I'd need to
differentiate between text and binary files.

Thanks again.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



nit [was RE: Segmentation Fault (was Re: CVS sticky information ignored on import)]

2002-04-09 Thread EXT-Corcoran, David

Just a little nit:
if you end the line with a | you can drop the \
 
> find . -name Entries | xargs grep "/-kb/" \
>   | sed -e "s|CVS/Entries:/||" -e "s|/[^/]*/[^/]*/-kb/.*||" \
>   | xargs cvs -d $CVSROOT admin -kb
> 

find . -name Entries | xargs grep "/-kb/" |
sed -e "s|CVS/Entries:/||" -e "s|/[^/]*/[^/]*/-kb/.*||" |
xargs cvs -d $CVSROOT admin -kb
 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs