[p4] nothing better about PVCS?

[Lee Marzke]

Davids,

I've had 10+ years experience with PVCS and am now totally sold on Perforce.
Like any tool, you must offset the learning curve of the new tool with the 
problems
it solves over the long term.

PVCS is a traditional SCM tool that has it's roots in UNIX RCS.   Perforce 
solves
almost all the PVCS issues ( and to be fair, does have a few minor one of it's
own. )

PVCS strengths:
1) Simple check-out model.  If the file is locked you can't check it out and
     you must wait until the previous locker has put it back.  ( Advanced PVCS
     options can get around this, but it is generally not advised to allow 
multiple
     locks because of the poor merge facilities on PVCS )

2) Everyone seems to understand this simple model ( as bad as it is ).

Perforce Strengths:
1) Multiple checkouts allows by default.   You have to go out of your way 
to lock
     the file.  This means that there is no good reason for any user to 
circumvent
     Perforce.     If two people modify a file, the last to check it in 
simple merges
     the two sets of changes.  ( Very often this can be done by the automated
     merge without any user decisions )

     Developers who simply don't want to deal with merges complain about not
     being able to lock their file from other changes.  In reality, they 
are the ones
     often circumventing the SCM system and causing problems.

  2) Works over the Internet, and over slow connections.
  3) Has a free web interface ( That does not require IIS and other costly 
servers )

PVCS Weaknesses:
1) Can't handle sub directories without manual workarounds.
2) Can't handle same filenames in different sub directories.  The GUI has 
folders
    which can't be nested.  The whole folder issue is controlled outside 
the "Version
    Control System"  IE ANYONE can change where the folder stores it's 
files and
    the next time you use the GUI your files get checked out to the wrong 
place.

3) Does not support moving source files to different directories.
4) Does not support deleting files. (  You can leave the file out of the 
Version Label, but
     this gets confusing with large number of files )
5) Branches are almost incomprehensible in larger projects.   There is no 
global
     "Branch Specification"  each file can be branched in a different 
way.  This is a nightmare
     with projects with over a few thousand files.
6) Enforcing security settings with the current interface requires 
tremendous effort.
    ( The many options and negate-options and GUI menu options often work 
together
     in ways you never quite expect )
7) The GUI and Command line interface can't be synchronized easily.   To 
get real
    synchronization you must create a parameter list ( or batch file ) for 
each GUI project
and  specify the long path the project config file.   These config files 
are on non-human
friendly directories created by the GUI, so there often is no way of 
guessing them by
browsing.

Luckily, I've had very good luck converting PVCS projects ( with over 
20,000 files ) to
Perforce with very good luck using the supplied Pvcs2P4 script.

I would suggest you ask your developers how PVCS handles sub directory
and other problems above and see what they say.

Lee Marzke <lee at n99.com>


At 01:02 PM 1/20/00 +0200, you wrote:
>Hello all,  I must pick an SCM tool in a short amount of time, and have
>heard alomost nothing but praise for Perforce; at the same time, internal
>resources have experience with PVCS, and as such, it is the default choice.
>I don't feel I'm getting a balanced perspective, because I've seen no
>argument for what PVCS does better than Perforce.  I need to make sure that
>I'm not overlooking something!
>
>Our project is a systems integration, combining a configurable applications
>running on Oracle8, on HP (can't modify the application code, only table
>configurations), another such application on SQL Server 7, on NT, custom
>interfaces in C, C++, VB on NT and UNIX, with all servers LAN connected.
>There will be three (build/test/production) environments, all of the above
>configuration, all Ethernet connected.
>
>So far thumbs up to Perforce, but a counterargument would be nice to hear
>(and may only confirm Perforce is still the right choice).
>
>Much obliged, Davids Sarma
>
>
>_______________________________________________
>perforce-user mailing list  -  perforce-user at perforce.com
>http://maillist.perforce.com/mailman/listinfo/perforce-user

--
=========================================================
Lee Marzke N84176 
(P28A)                                              <lee at n99.com>
Flight Instructor, TAS Inc.
Software Engineering Consultant
Linux Servers, Linux/Win Integration, Avionics,  PVCS / Perforce SCM
=========================================================