[p4] typemap with +k

[David Weintraub]

> I remember something in the docs that if the server doesn't have a type
> mapping for a file the server does some magic to determine how to store
> the file.  To be able to tap into that with a trigger could be very
> useful.
>

It's in the Administrator's Manual in Chapter 3

>Defining filetypes with p4 typemap
>-------------------------------------------------

> By default, Perforce automatically determines if a file is of type text or binary based on
> an analysis of the first 8192 bytes of a file. If the high bit is clear in each of the first 8192
> bytes, Perforce assumes it to be text; otherwise, it is assumed to be binary.

> Although this default behavior can be overridden by the use of the -t filetype flag, it's
> easy for users to overlook this consideration, particularly in cases where files' types are
> usually (but not always) detected correctly. Certain file formats, such as RTF (Rich Text
> Format) and Adobe PDF (Portable Document Format), can start with a series of comment
> fields or other textual data. If these comments are sufficiently long, such files can be
> erroneously detected by Perforce as being of type text.

If you want to follow this behavior in a trigger, you may want to look
at the Unix "file" command which does something similar. The "file"
command looks at a "magic" file to determine the file type. It
examines the suffix, the first few hundred bytes, etc. This could be
put into a trigger.

If not, you could write a simple Perl script that reads through the
first 8K bytes and examines them for any out-of-range byte values.

I would recommend that anyone who wants to turn on RCS keywords for
all text files to thinks about it for a while. In RCS, it was the only
way you knew which version of a file you were looking at, or who
edited it. However, in Perforce, this information is readily available
via various "p4" commands.

I would only turn on RCS keywords very selectively -- maybe just one
or two files. As long as developers are in Perforce, RCS keyword
expansion really doesn't accomplish that much. Where it might come in
handy is when a file is on a client's machine, so you can verify which
release someone is on. Something that a client or technician can
quickly reference.

Even there, this could easily be handled by a build script that
implants the release label into the release itself which is probably
more useful than that file's particular revision number.

On 3/8/07, Jamison, Shawn <sjamison at ciena.com> wrote:
> It would be nice if we could hook into the functionality the P4D server
> has to determine if a file is a text or binary.
>
> I remember something in the docs that if the server doesn't have a type
> mapping for a file the server does some magic to determine how to store
> the file.  To be able to tap into that with a trigger could be very
> useful.
>
>
> -Shawn J>
> Perforce Admin
> Ciena Corp.
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of
> Jamie.Echlin at barclayscapital.com
> Sent: Thursday, March 08, 2007 8:03 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] typemap with +k
>
> Hrm, thanks for that. We have put in a RFE. We need to do something in
> the typemap like
>
> +k //....(isPlainText?)
>
> Or whatever. Relying on extensions is a recipe for trouble, eg .prc is
> used by Rational Rose (binary), but also for stored procs (text), Word
> .docs are binary, Framemaker ones are not.
>
> Not to harp on about clearcase, but take some examples of the equivalent
> of the typemap:
>
> directory : -stat d ;
> c_source source text_file : -printable & -name "*.c" ; sh_script script
> text_file : -printable & (-name ".profile" | -name
> "*.sh") ;
> archive library file: !-printable & -name "*.a" ;
>
> Etc...
>
> Cheers, jamie
>
>
> > -----Original Message-----
> > From: Jamison, Shawn [mailto:sjamison at ciena.com]
> > Sent: 08 March 2007 12:49
> > To: Echlin, Jamie: IT (LDN); perforce-user at perforce.com
> > Subject: RE: [p4] typemap with +k
> >
> > I had the same kind of issue with a different OS.
> > You will need to implement and rely on file extensions and/or naming
> > conventions.
> >
> > Otherwise remove the global +k type mapping and you or your developers
>
> > will have to manually add the +k type map to all new files.
> >
> > At least that is what I had to do...the file extensions and naming
> > conventions part that is!
> >
> > -Shawn J>
> > Perforce Admin
> > Ciena Corp.
> >
> > -----Original Message-----
> > From: perforce-user-bounces at perforce.com
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of
> > Jamie.Echlin at barclayscapital.com
> > Sent: Thursday, March 08, 2007 6:48 AM
> > To: perforce-user at perforce.com
> > Subject: [p4] typemap with +k
> >
> > Hi,
> >
> > We have a particular area of the depot where we want +k on text files,
>
> > regardless of type (pl, pm, java and so on)... So we naively changed
> > the typemap to have:
> >
> > +k //depot/somearea/...
> >
> > Assuming that the +k would only apply to text files. Now this area
> > also contains various binary files, images and excel templates, many
> > of which I now see are "corrupted" by the keyword expansion.
> >
> > Short of listing ALL the file extensions where we may ever want the
> > keyword expansion, is there any alternative? In ClearCase for instance
>
> > you have a "plain text" test, so you can say, is it plain text? If so
> > store it as xyz...
> >
> > I guess a post-commit trigger could accomplish the same thing, as you
> > could be a bit more intelligent about what is plain text. In general I
>
> > don't like relying on extensions, many programs use the same extension
>
> > name for storage of different files, and on unix having a file
> > extension is not so much a convention.
> >
> > Cheers, jamie
> >
> > --------------------------------------------------------------
> > ----------
> > For more information about Barclays Capital, please visit our web site
>
> > at http://www.barcap.com.
> >
> > Internet communications are not secure and therefore the Barclays
> > Group does not accept legal responsibility for the contents of this
> > message.
> > Although the Barclays Group operates anti-virus programmes, it does
> > not accept responsibility for any damage whatsoever that is caused by
> > viruses being passed.  Any views or opinions presented are solely
> > those of the author and do not necessarily represent those of the
> > Barclays Group.  Replies to this email may be monitored by the
> > Barclays Group for operational or business reasons.
> > --------------------------------------------------------------
> > ----------
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
--
David Weintraub
qazwart at gmail.com