Rcs Kflg Opções Binárias

Ao adicionar arquivos, o Perforce examina primeiro a tabela typemap para ver se o administrador do sistema definiu um tipo de arquivo para o (s) arquivo (s) que está sendo adicionado. Se for encontrada uma correspondência, o tipo de arquivos é definido como definido na tabela typemap. Se uma correspondência não for encontrada, o Perforce examina os primeiros bytes do arquivo com base no filesys. binaryscan configurável (por padrão, 65536 bytes) para determinar se ele é texto ou binário. E os arquivos são armazenados no depósito de acordo. Por padrão, as revisões de arquivos de texto são armazenadas em formato de delta reverso, os arquivos de texto recém-adicionados maiores que o limite imposto pelo filetype. maxtextsize configurável (por padrão, 10 MB) são atribuídos ao tipo de arquivo textC e armazenados na íntegra. Os arquivos compactados no formato. zip (incluindo arquivos. jar) também são automaticamente detectados e atribuídos ao tipo ubinary. Outras revisões binárias são armazenadas na íntegra, com compressão. Os administradores Perforce podem usar o recurso de mapeamento de tipo (p4 typemap) para substituir o mecanismo de detecção de tipo de arquivo padrão Perforces. Esse recurso é útil para formatos de arquivos binários (como o Adobe PDF ou Rich Text Format) onde os arquivos podem começar com grandes porções de texto ASCII e, de outra forma, poderiam ser confundidos com arquivos de texto. Os administradores Perforce podem usar os configuradores filesys. binaryscan e filetype. maxtextsize (consulte p4 configure) para alterar os limites padrão de 65536 bytes para detecção de texto / binário e o limite de tamanho do arquivo de texto RCS de 10 MB, respectivamente. O armazenamento Delta (o modo padrão com arquivos de texto) é um método pelo qual apenas as diferenças (ou deltas) entre revisões de arquivos são armazenadas. O armazenamento completo de arquivos (o modo padrão com arquivos binários) envolve o armazenamento de todo o arquivo. O tipo de arquivos determina se o arquivo completo ou o armazenamento em delta são usados. Perforce usa o formato RCS para armazenamento delta. Alguns dos tipos de arquivo são compactados para o formato gzip para armazenamento no depósito. A compressão ocorre durante o processo de envio e a descompressão ocorre durante a sincronização. O processo é transparente para o usuário o espaço de trabalho do cliente sempre contém o arquivo como ele foi enviado. Os links simbólicos em espaços de trabalho de cliente não UNIX aparecem como pequenos arquivos de texto contendo um caminho relativo para o arquivo vinculado. A edição desses arquivos em um cliente não-UNIX deve ser feita com cautela, uma vez que enviá-los para o depósito pode resultar em um link simbólico apontando para um arquivo inexistente na área de trabalho do UNIX. Por exemplo, a alteração de um tipo de arquivos adicionando o modificador S n (objeto temporário) indica à Perforce para armazenar somente as revisões n mais recentes do arquivo no depósito. Se você alterar um arquivo existente em um objeto temporário, as revisões subseqüentes (após o n º) irá limpar as revisões armazenadas após a revisão da cabeça antiga, mas as revisões para o arquivo armazenado no depósito antes que o modificador S n fosse usado permanecerão inalteradas. (A sincronização com uma revisão não-cabeça enviada depois que o modificador S n foi usado irá excluir o arquivo da sua área de trabalho.) Tais revisões são exibidas como operações de purga na saída de p4 filelog.) Executando p4 integrar em arquivos de objetos temporários (S e S N) não produz uma cópia preguiçosa o arquivo tempobj integrado consome espaço em disco adicional no servidor. O modificador modtime (m) é um caso especial: destina-se a ser usado por desenvolvedores que precisam preservar um timestamp original de arquivos. (Se um espaço de trabalho cliente usa a opção modtime, a data do arquivo não é garantida para avançar para cada revisão. Por exemplo, se um arquivo é cópia integrada (aceitar o deles), seu timestamp irá refletir o do arquivo de origem. Se um usuário verifica Em um arquivo com uma data antiga, o arquivo de espaço de trabalho do cliente refletirá a mesma data antiga. Normalmente, o Perforce atualiza o timestamp quando um arquivo é sincronizado a opção modtime permite que um usuário garanta que o timestamp de um arquivo em um espaço de trabalho cliente após Uma sincronização p4 será o timestamp original existente no arquivo no momento da submissão (ou seja, não o tempo no servidor Perforce no momento da submissão, e não o tempo no cliente no momento da sincronização). Caso isso seja útil é o desenvolvimento envolvendo as DLLs de terceiros freqüentemente encontradas em ambientes Windows. Porque os carimbos de data / hora em tais arquivos são freqüentemente usados ​​como proxies para informações de controle de versão (tanto no ambiente de desenvolvimento como também pelo sistema operacional), às vezes Necessário para preservar os arquivos timestamps originais, independentemente de um Perforce configurações de cliente de usuários. O modificador m em um arquivo permite que isso aconteça se definido, o Perforce ignorará a configuração de opção modtime (data timestamp no momento da submissão) ou nomodtime (data e hora no cliente no momento da sincronização) do espaço de trabalho cliente ao sincronizar o arquivo , E sempre restaurar os arquivos timestamp original no momento do envio.