Quick Perforce Guide

Рубрика: Development | 14 February 2008, 16:55 | juriy

On a project that I’m currently working with we’re using perforce as a version control system. I’ve found that mostly team members are having troubles understanding it besides official guide is rather large and information-intensive. So I’ve written a short guide for my team. I guess it will be useful for other people too. So here it is.

Quick Perforce Guide.
Perforce is a powerful and flexible version control system (VCS). Perforce is a commercial product and due to that reason is not spread as widely as Subversion. Nevertheless it’s popular and widely supported in modern IDEs. This guide is Windows-oriented: some details (mostly minor) may vary from platform to platform but general concepts are the same.

This guide assumes that you’re already familiar with concepts of version control and have at least some experience using other VCS like Subversion and CVS.

0. Intro.
The main difference between perforce and CVS/SVN is that perforce stores all meta-information on server. Absolutely everything. No files, except project files will be ever added by perforce to your filesystem. It’s really good: you cannot corrupt anything. It’s a bit bad: you have to stay connected to perforce server to do your work.

1. Install perforce client.
Perforce clients are freely available from perforce web page. Select your platform from the list and then select P4V Installer. This package contains some useful visual tools along with command line tools. Install the software. Installation wizard should prompt you for a server name, port, path to editor application (typically, notepad.exe) and your perforce username. Enter appropriate values.

P4V setup

When installation procedure is completed try to execute

> p4

You should see output similar to this:

Perforce -- the Fast Software Configuration Management System.

p4 is Perforce's client tool for the command line. Try ...

this means that command line client is installed and working.

If you see something like the following

Perforce client error:
Connect to server failed; check $P4PORT.
TCP connect to tgperforce.de.db.com failed.
tgperforce.de.db.com: host unknown.

don’t panic. This means that perforce client simply unable to connect to server. The reason might as trivial as misspelled server name or firewalls that do not allow client to send data.

2. Install Arasix Merge.
Even though perforce package has a tool for merging I prefer using specialized third-party tools developed specifically for that single purpose. The good choice is Araxis Merge. It isn’t free yet it worth using. Download and install packages from http://www.araxis.com/merge/.

3. Setting up perforce environment.
Perforce uses several variables that are worth mentioning here. Three of them: P4EDITOR, P4USER and P4PORT we’ve already set implicitly during tools installation. To display currently used perforce variables type:

> p4 set

The output should be similar to the following

P4EDITOR=C:\WINDOWS\system32\notepad.exe (set)
P4PORT=perforce:2828 (set -s)
P4USER=juriy (set)

To set variable type


Now set your perforce password:

> p4 set P4PASSWD=s3cret

Now we should tell perforce which software to use for diff’ing and merging. In our case it’s Araxis Merge. Set two more variables:


Change araxis installation path according to where you’ve installed it.

There’s the way to set a file where perforce should look for it’s properties. To do it just set another variable: P4CONFIG. In my case I’ll call perforce configuration file “p4config” just the same as variable name except case. In that file you may set any properties in the same manner:


Now it’s time to checkout project from perforce.

4. Grabbing a project.
First of all you need to know where your project is located under depot tree. The paths in the depot tree looks quite like a paths in a filesystem. Depot root is marked as double-slash (//) and delimiters are single slashes (/). A typical perforce path may look like this:


Three dots (…) is a wildcard that matches everything under current directory recursively.

To get files from perforce you have to create a client workspace specification. Or simply “client spec” or even simpler “client”. Client is a set of rules in a form of a text file that define how a part of a depot is mapped to a local filesystem. To create a new client view type

> p4 client

A notepad window should appear with a default client specification. It maps every folder under depot root to the same folder on a workspace.

Edit a text file. Pick a unique name for a client and type it near “Client: “. For now I’ll take a name tut_clnt. Make sure that “Root:” points to folder where you need the project files. Delete everything under “View” and type correct mapping:

//projects/foo/... //tut_clnt/...

Left part is a depot path, right part is a client path. In this way s part of depot tree (//projects/foo/…) is mapped to a client (//tut_clnt/…) and the client’s root is c:\apps\projects\tutor. So //projects/foo/… will be written to c:\apps\projects\tutor.

After editing a file should look like this:

# A Perforce Client Specification.
# Client: The client name.
# Update: The date this specification was last modified.
# Access: The date this client was last used in any way.
# Owner: The user who created this client.
# Host: If set, restricts access to the named host.
# Description: A short description of the client (optional).
# Root: The base directory of the client workspace.
# AltRoots: Up to two alternate client workspace roots.
# Options: Client options:
# [no]allwrite [no]clobber [no]compress
# [un]locked [no]modtime [no]rmdir
# SubmitOptions:
# submitunchanged/submitunchanged+reopen
# revertunchanged/revertunchanged+reopen
# leaveunchanged/leaveunchanged+reopen
# LineEnd: Text file line endings on client: local/unix/mac/win/share.
# View: Lines to map depot files into the client workspace.
# Use 'p4 help client' to see more about client views and options.

Client: tut_clnt

Owner: Juriy

Host: Juriy

Created by juriy.

Root: c:\apps\projects\tutor

Options: noallwrite noclobber nocompress unlocked nomodtime normdir

SubmitOptions: submitunchanged

LineEnd: local

//projects/foo/... //tut_clnt/...


Save the file and close the editor.

To use client you have to define another variable P4CLIENT. But setting it in a straightforward way is not the best solution. If you’re planning to work with multiple views you’ll have to reset this variable every time. That’s not good.
A better solution is to create a text file, set client name there and then point P4CONFIG to that file. Try it out. Create a text file (call it p4config) type

P4CLIENT =tut_clnt

Save it. Now define another variable:

> p4 set p4config=p4config

Type p4set once more. Make sure that perforce has found the file and p4client variable is available.

Now it’s time to get files from depot. Type

> p4 sync

That’s it. Your files are your hard drive.

5. Editing files.
Note that all files were checked out as read-only. To enable editing of the file foo.java type

> p4 edit foo.java

you should see

… foo.java#1 - opened for edit

Now edit a file in your favorite text editor, save it and type

> p4 submit

Now the file is submitted to a repository and again it has a read-only status.

Now let’s create another file foo.txt. It will not be added to repository once you type p4 submit. You have to tell perforce explicitly to add a file:

> p4 add foo.txt

foo.txt is not yet added to a repository. To add a file issue submit again.

> p4 submit
Now let’s remove file from repository

> p4 delete foo.txt

Once again, until issuing p4 submit the repository remains intact – the changes are only made to a local workspace.

To revert changes issue

> p4 revert

That’s the basis of working with files in perforce. See guide for more detailed explanation.

6. Working with branches.
In perforce branches “is a method of maintaining the relationship between sets of related files” as official guide says. This definition isn’t making anything clearer. In other words branch is a copy of some part of repository tree. The concept is just the same as with subversion or CVS. For example, if you’re planning to make serious changes to a project, it’s a good idea to create a separate branch, perform changes there, and then integrate changes back to main branch.

The best way to create a branch is to make a branch specification. It is quite similar to client specification but it maps part of depot to another part of depot instead of depot-to-filesystem mapping.

To create a branch specification issue following command

> p4 branch branchname

A text editor should open. In a “View” set depot-to-depot mapping. On the left side point to an existing depot location, on the right side point where to create a new branch. For example:

//projects/foo/main/... //projects/foo/dev/...

The overall specification might look like that.

# A Perforce Branch Specification.
# Branch: The branch name.
# Update: The date this specification was last modified.
# Access: The date of the last 'integrate' using this branch.
# Owner: The user who created this branch.
# Description: A short description of the branch (optional).
# Options: Branch update options: [un]locked.
# View: Lines to map source depot files to target depot files.
# Use 'p4 help branch' to see more about branch views.

Branch: developmentBranch

Update: 2008/02/12 16:24:02

Access: 2008/02/12 16:24:02

Owner: yuri

Created by yuri.

Options: unlocked

//projects/foo/main/... //projects/foo/dev/...

Now a branch specification is created. But files are not actually copied anywhere until you issue

> p4 integ -b branchname

Now your branch is done.
Every time when you need to update “dev” from “main” you should perform

> p4 integ -b branchname

And when you want to propagate changes back (from “dev” to “main”) use

> p4 integ -b branchname -r

This new flag “-r” means “reverse”.

Now let’s try to make some changes both in “dev” and in “main” and then integrate from dev to main. Here’s a diagram that explains what we’ll do.


We have a file in Main that already has some content. Then we decided to make a branch and the file is copied to Dev. Then it was changed independently in Main and in Dev. Then we’re trying to integrate changes from Dev back to main. At this moment we’ll definitely have a conflict.

To resolve conflicts in perforce there’s a special command resolve. If you issue resolve with no arguments – perforce will prompt you to resolve every conflict manually – such behavior can easily cause an overhead, especially while integrating few dozens of files. A better solution is to try to resolve conflicts automatically. To do it simply type

> p4 resolve –am

If some files couldn’t be resolved automatically – you’ll have to issue manual resolve.

> p4 resolve –am

Still it’s far better then resolving everything by hand.
Here’s a console snapshot of what was explained above.

>p4 integ -b devBranch
//projects/foo/dev/foobar.txt#1 - branch/sync from //projects/foo/main/foobar.txt#3

>p4 submit
Change 940242 created with 1 open file(s).
Submitting change 940242.
Locking 1 files ...
branch //projects/foo/dev/foobar.txt#1
Change 940242 submitted.
//projects/foo/dev/foobar.txt#1 - refreshing

C:\apps\projects\tutor>p4 edit //tut_clnt/.../foobar.txt
//projects/foo/dev/foobar.txt#1 - opened for edit
//projects/foo/main/foobar.txt#3 - opened for edit

>p4 submit
Change 940245 created with 2 open file(s).
Submitting change 940245.
Locking 2 files ...
edit //projects/foo/dev/foobar.txt#2
edit //projects/foo/main/foobar.txt#4
Change 940245 submitted.
//projects/foo/dev/foobar.txt#2 - refreshing
//projects/foo/main/foobar.txt#4 - refreshing

>p4 integ -b developmentBmetDelme -r
//projects/foo/main/foobar.txt#4 - integrate from //projects/foo/dev/foobar.txt#2

>p4 resolve -am
c:\apps\projects\tutor\main\foobar.txt - merging //projects/foo/dev/foobar.txt#2
Diff chunks: 0 yours + 0 theirs + 0 both + 1 conflicting
//tut_clnt/main/foobar.txt - resolve skipped.

See last 2 lines. They indicate that there’s a conflict that couldn’t be resolved automatically. Now we should try manual resolve.

>p4 resolve
c:\apps\projects\tutor\main\foobar.txt - merging //projects/foo/dev/foobar.txt#2
Diff chunks: 0 yours + 0 theirs + 0 both + 1 conflicting
Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) e: m

Type “m” (merge) in the prompt and hit enter. Araxis Merge should now open and show you 3 files called yours, theirs and common ancestor.

Araxis merge

Yours is the file in the branch that you’re integrating to. In this case we’re integrating to main – so it’s a file from main branch (file at the right panel). Theirs is the file in branch that you’re integrating from. In this case we’re integrating from Dev so it is the file from that branch. Common ancestor is the closest common version of conflicting files.

You can only edit yours. Now resolve conflicts, save “yours” and close the file. In appeared console prompt type “am” – “Accept Merged”. You have other options too: at – Accept Theirs, ay – Accept Yours, etc. Remember: everything you’ve just performed is not yet submitted to the server. You can revert changes if you didn’t like merge results and perform integration again.

That’s it about resolving conflicts for now. Refer to official manual for further info.

Let’s say you’ve done a v.1.0 of your software and you want to save the state of your project at this moment so that you can continue working with the files and still have an option to build a project as it was in v.1.0. A label is just the thing you need. “A Perforce label is a set of tagged file revisions” as official guide says. Just as client workspace and a branch every label has a label specification.

In this guide I’ll show just a basic usage of labels: “freezing” current workspace with label and then retrieving the workspace snapshot.

First of all you have to create a label:

>p4 label tutLabel
Label tutLabel saved.

Then you have to issue p4 labelsync. This command tells perforce to tag all synced files to be added to label:

>p4 labelsync -l tutLabel
//projects/foo/main/foobar.txt#5 - added

Now you can view the “content” of the label by issuing p4 files @labelname.

>p4 files @tutLabel
//projects/foo/main/foobar.txt#5 - integrate change 941054 (ktext)

To retrieve files tagged by label issue

>p4 sync @tutLabel
//projects/foo/dev/foobar.txt#2 - deleted as c:\apps\projects\tutor\dev\foobar.txt
//projects/foo/main/foobar.txt#5 - updating c:\apps\projects\tutor\main\foobar.txt

Note that all files that are not in label were deleted so now the workspace exactly represents the “frozen” state.

To restore the workspace – issue sync with no arguments.

That’s the end of a basic perforce guide. You’ve learned how to retrieve project from depot, edit, submit and revert files, work with branches and labels. That’s quite enough to complete most of tasks in a project. Still it’s a good idea to read official perforce guide to learn about more advanced features.

Комментариев: 29

29 Responses to “Quick Perforce Guide”


  1. Chabster

    Perforce – лучший сорс контрол.

  2. Farcaller

    > Perforce – лучший сорс контрол.

    можно аргументировать как-то? Я что-то особых плюсов не заметил пока кроме полного server-side храниния метаданных (накрылся сервер и упало *вообще* все..)

  3. Chabster

    > Farcaller
    Поработай над оооочень распределенном по планете проектом и поймешь, что svn – полнейшая дрянь, cvs сильно тормозит и подвержен ошибкам при чекинах, а все остальные сорс контролы с блокировками редактирования не подходят по соображениям скалабельности.

  4. Farcaller

    > Поработай над оооочень распределенном по планете проектом

    Linux kernel подходит? ;)

    Торвальдс под него даже свой RCS написал, git. Так там подход как раз противоположный, *все* метаданные на клиенте. Собственно говоря даже сервер не нужен, можно патчи хоть через мейл-лист передавать (поддержка ML встроена ;) ). Кроме того над базовой архитектурой есть несколько надстроек, например st-git, который раскладывает разные репозитории стеком (т.е. есть мастер-репозиторий, набор патчей A, набор патчей B, который зависит от A, и все это можно обновлять независимо).

    Собственно я git использую вообще для всех локальных проектов, которые выросли из “local hostory” eclipse’а. Элементарная инициализация + простота в использовании.

    Ну и компрессия. Мой рабочий бранч linux’а занимает 250Mb деревом гита (около трех сотен ревизий).

  5. Vadim Voituk

    Чабстер опять в своем стиле – бросает громкие заявления в стиле “вы все ещё аматоры – слушайте умного опытного дядя”, а аргументов не приводит.

    P.S. Когда это ты уже успел поработать над “оооочень распределенным” проектом?
    P.S.S. Кстати я тож не вижу преимуществ P4 перед более популярными VCS.

  6. Chabster

    1) VCS – это маленькая часть всего комплекса программ разработки, которые должны интегрироваться друг в друга
    2) git? – пусь неудачник Торвальдс его использует хоть в гробу
    3) CVS не поддерживает атомарные чекины
    4) SVN – это только для проектов под названием “Hello world”
    5) SVN не поддерживает бранчи
    6) CVS и SVN создают на диске кучу левых файлов и папок
    7) Бранчевание и мерж в CVS – сложная процедура, т.к. выполняется ооооочень долго и в на это время нельзя запретить чекины
    8) Ни CVS и SVN не имеют удобных GUI
    9) SVN и CVS при большом кол-ве файлов и бранчей в репозитарии медленные

    Поищите в гугле о преимуществах перфорса, че я этим занимаюсь?

    I have personally used both CVS and Perforce extensively. And when I moved from CVS to Perforce, it definitely was an “upgrade”. A few of the really good reasons why the 750 bucks is worth it
    a. A commit is a transaction – How many times have you started a long checkin on CVS, and the network or something goes down, and you have code breaking. In P4, an entire commit(submit) is an atomic operation. This is a real blessing, because you can be sure that a checkin will never break the code (Provided you have verified it doesn’t before checking in!!!)
    b. P4 is not as chatty as CVS – P4 maintains state on the server, which means you do not have those dirty /CVS directories in your code. What CVS does in order to do an update is, it communicates to the server(repository), which version of the file it has. Then the server figures which file version to give it. And this is done for each directory in turn! The volume of communication is very large between the client and server.
    c. P4 maintians labels as references to the file versions instead of placing a marker on the physical file itself.
    d. P4 maintains differenct branches as distinct files – Unlike CVS where all branches of a file are marked on the same repository file
    The above two combined, give you a much superior performance when it comes to labelling and branching. I have persoanlly faced situations where we have had to maintain a large number of branches, and releases on each of these branches.
    CVS locks each file its trying to label, and if you are labelling the whole source tree, every developer’s work is pretty much frozen. In P4 labelling a whole source tree (of about 5000 files) takes 2 minutes flat.

    Apart from this, pretty much everything that CVS provides is provided by P4, including watching, auditing etc.

    The bottom line is this: If you are working on a really large project, with a lot of source branches go for P4. If you are working on a WAN (as we are) go for P4. If you run a single or dual branch software shop, with everyone sitting in the same place, go for the free alternative. You won’t notice the difference.

  7. juriy

    Да ладно, можно и в обратную сторону найти цитату немного погуглив.

    Consider the standard use case for a version control system: editing files, and then committing those changes back to the repository. If you are using Subversion, you simply edit the files in place. When you are ready to commit, you issue a ’status’ command to get a quick overview of files that have been changed, files that have been added, and files that have been deleted. You may choose to add some files that are not under version control, revert some files that shouldn’t have been edited, and then issue the commit command to finalize your session.

    Now consider the same case under Perforce. You go to edit your first file, only to realize that it is read-only, requiring you to first ‘open it for edit’. After a number of edits, you decide you need to add a new module to your program. Don’t forget to add this file to
    Perforce, because as far as I know, there is no way in Perforce to get a list of files that are not under version control. How many times has someone in your organization broken the build because they forgot to add a new file to Perforce? You then decide that you want to run a script to edit a large number of files. After you have modified these files to be read-write, you run the script, but then realize Perforce has not picked up the changes in ‘Pending Changelists’ screen. Of course not, because you didn’t explicitly open these files for edit! After you are ready, you issue the ’submit’ command to check in your


  8. Vadim Voituk

    1. Что, кроме VCS, P4 умеет ещё делать такого, что не умеют другие VCS?
    2. Согласен, только “неудачник Линус” живет припеваючи и ездит на BMW Z5, а “удачливый Чабстер” – на метро:)
    3. Согласен. Главный повод перейти на SVN
    4. Опять утверждение без аргументов
    5. Поддерживает, причем “maintains different branches as distinct files – Unlike CVS” (цитата из твоего комментария)
    6. Это и есть метаданные и где их хранить лучше – отдельный разговор (см. комментарий №2 от Farcaller)
    7.1. В чем сложность процедуры то?
    7.2. Медленноть (следствие хранения метаданных на клиенте?) – ещё не стыкался с НАСТОЛЬКО большими проектами.
    8. Имеют на любой вкус и цвет.
    9. Тут спорить сложно (См. 7.2)

    Ну и вдогонку http://rentzsch.com/notes/whyNotPerforce

  9. Farcaller

    2) гм. убежденный виндузятник что-ли? http://repo.or.cz это только один из бесплатных git-хостингов, но по количеству проектов уже можно судить. git не очень прижился в коммерческой среде, т.к. там нет необходимости в распределенной, зачастую независимой, разработке.
    4) ху*се о_О
    5) все он поддерживает, просто это сделано не так как у всех.
    8) насчет CVS я не знаю, но к svn есть много красивых гуев. Хотя мне как-то проще работать с ним из консоли, я diff’ы плохо воспринимыю во всех этих утилитках, unified diff как-то привычнее.
    9) у svn это зависит только от конкретных бекендов и файловых систем.

    что касается мусора в дереве, то да, svn этим болеет. У git’а все лежит в одном каталоге.

    Я думаю, что дальше спорить на блоге о том, какая RCS рациональнее – не стоит. Флудить надо с пивом :)

  10. Chabster

    Это все ерунда, Юра. А плагины есть почти под все IDE. В отличие от CVS или SVN.


  11. Chabster

    Vadim Voituk:
    Я могу только еще раз посторить: SVN не поддерживает бранчи. Всех, кто считает, что копия файла – это бранч, отправляю курить чай.

    > Ну и вдогонку http://rentzsch.com/notes/whyNotPerforce
    Начал читать, по-сути ниче не написано.

  12. Farcaller

    /me пошел курить чай с манами и заедать мягкими французскими булочками

  13. Vadim Voituk

    Обьясни мне 2 вещи:
    1. Что тебе не нравится в сущетвующих CVS/SVN плугинах для популярных IDE? Только не общим фразами, а конкретно по отдельному плугину.
    2. Как делает бренчи P4?
    Выше ты писал (комментарий#6)

    “d. P4 maintains differenct branches as distinct files”

    Также как и в SVN

  14. Vadim Voituk

    И ещё:
    Если у тебя удаленный p4-репозитарий, то тебе для работы с ним нужно постоянное соединение?

    P.S. У тя на скриншоте “свой” репозиторий? Дай “на попробовать”

  15. Chabster

    > Vadim Voituk
    Найди нормальную графическую оболочку для CVS, которая не является надстройкой над cvs.exe.
    Найди плагин для CVS под, скажем, самую распостраненную IDE – Visual Studio.
    > “d. P4 maintains differenct branches as distinct files”
    CVS все ревизии файла держит в одном файле. Это значит, что и ревизии после бранчевания тоже идут в этот файл. В результате скорость доступа падает порядочно.

    SVN не поддерживает бранчи. Файл просто добавляется заново, история бранчевания и мержа НЕ СОХРАНЯЕТСЯ.

    P4 держит отбранчеванный файл в отдельном файле (если можно так говорить, ибо у него база данных репозитария), при этом вся история бранчевания\сливания сохраняется. http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html

  16. Chabster

    Короче говоря, Perforce – это современный CVS.

  17. Vadim Voituk

    1. С бранчеванием вроде понял – реально P4 в этом смысле круче.

    2. Я не работаю с VS уже года так 3-4 – потому как пример приведу нормального IDE-плугина приведу поддержку CVS/SVN в Eclipse. Думаю и в IDEA дела не хуже обстоят.

    P.S. С какого перепугу VS стало самой распостраненной IDE?

  18. Chabster

    > Vadim Voituk

    You can work on your versioned files when disconnected from the Perforce server, however, you will not have any access to Perforce server functions when working disconnected.

    Как и в любом другом VCS.

    Недам, влом права настраивать)

  19. Chabster


    Microsoft Visual Studio remains the most widely used IDE (integrated development environment) among software developers, Evans Data Corp. reports. The analyst firm’s findings were based on data collected from over 1,200 developers worldwide, regarding the features and capabilities of 11 of the top IDEs, it says.

  20. Vadim Voituk

    Так и хочется сказать “На заборе тоже написано” –
    это же надо было додуматься привести ссылку на сайт, спонсируемый Microsoft :)


  21. Chabster

    > Vadim Voituk
    Найди где написано про еклипс)))

    http://www.march-hare.com/cvsnt/features/scci/ – даже евалюейшена нету для скачивания. На слово верить? Или ты полагаешь, что я активно не искал плагины?)))

  22. Farcaller

    Гыгыгыгыгыгы! извините, вырвалось. Нет, ну можно и на “Get the facts” поити и прочитать, какой виндовс секюрный, быстрый, навороченный, бла-бла-бла

    В git’е (svn вроде Вайт уже неплохо отстаивает, я про git рассказывать буду) бранчи с историей и всем-всем хранятся.

  23. Chabster

    > Farcaller
    Скажи, а какие есть сертификаты безопасности у твоей рабочей ОС?
    Предупреждаю сразу: знаком с юниксами куда лучше, чем с виндой.

    Я про git слышу впервые. Производители ЖЦП систем, вероятно, тоже. Может, он и лучше, но, он используется и поддерживается узким кругом ОПЕН-СОРС разрабов. А там, где деньги, их не любят).

  24. Farcaller

    сертификаты безопасности? WTF (перефразируй или поясни)? У меня связь между локальным компом и сервером RSC без проблем шифруется хоть по ГОСТ 28147-89.

    git используется например у сименсов.

    кстати он 100%-совместим с svn в обе стороны (т.е. ты можешь использовать локальное дерево git с удаленным сервером svn). Так что можно извлечь плюсы обоих систем.

    P.S.: ЖЦП – это что?

  25. Chabster

    > Farcaller
    ЖЦП – это штука, на которую опенсорс ложит большой 8========Э.

    > поити и прочитать, какой виндовс секюрный, быстрый, навороченный, бла-бла-бла

    Если напрячь пальцы, то можно узнать, какие сертификации прошла Винда по безопасности. Также можно узнать, что ни один бесплатный Юникс не имеет такого сертификата. Также можно узнать, что ГОСТ не признается международными организациями, т.к. содержит бекдоры, а винда будет сертифицирована по непомнюужекакой херне насчет криптографии.

    Совместимость в SVN никому не нужна. Нужно, чтобы с файлом можно было при инспекции кода связать дефект. Нужно, чтобы код, который не был проинспекчен, не попадал в рабочую версию репозитария. И т.д.

  26. Farcaller

    Ага, а в RSA бекдоров нет, и в винде бекдоров нет, и вообще NSA совсем не при делах, т.к. Windows самый труъ.

    Я действительно не знаю, что такое ЖЦП. Не можешь объяснить нормально – лучше б не комментил.

    Мне как-то пофиг на международные организации. Мы сотрудничаем… ну назовем это абстрактным бюро безопасности. Если нам будет нужен независимый метод шифрования, в эллиптических кривых можно долго ковыряться.

    И мне опять же пофиг на сертификаты. Код VxWorks я видел, и модуль криптографии тоже. И результаты аудита. А код винды я не видел.

    Чабстер, мне кажется что отвечать на конкретно заданные вопросы у тебя не выходит совсем, чем ты мне очень напоминаешь неких аналитиков с linux.org.ru. Так что лично я прекращаю дискуссию здесь и сейчас. dixi.

  27. Chabster

    Правильное решение!

  28. Андрей

    Evaluation Assurance Level – самый популярный способ сертификации секьюрности ОС, которым руководствуются к примеру при выборе ОС правительственные органы США. Самое большое достижение Виндовс в этой области — EAL 4 у Windows 2000 SP 3. Такой же уровень сетрификации имеют SUSE Enterprise Server 9 и RedHat Enterprise Linux 5. Так что в области сертификации секьюрности достижения виндовс и линукс можно сказать равны.

  29. Chabster

    Коммерческий линукс ;) Именно поэтому я предпочитаю RedHat EL, а у господина фарколлера, вероятно, самосборка. Но раз он видел ее код (пару гигабайт), значит можно быть спокойным! Ггг.

    Ну, че с топика то уехали? Тут же о Perforce.

Leave a Reply