> > > RCS about trashed one archive a week it was abysmal slow - especialy on
> > > lage binary files (Visual Builder Binary, VBB). And one in 4 over night
> > > compiles faild because auf RCS get did not get all the files. And another
> > one
> > > because of user error due to the not existing user interface.
> > > Now we have PVCS and it has paid for itself in about a month with
> > > improved perfomance alone. Not to mention the removed headache of all
> > > the other problems.
> > Gosh, someone that likes PVCS. I think PVCS (v5.2/v5.3) is one of the most
> > abysmal applications that I have come across. I'm currently doing some work
> > at a company where there is virtually open revolt against it - the
> > developers universally hate it. The command line is mostly just about
> > usable (other than all the shell metacharacters that are needed - not good
> > if you're using it on Unix), but the GUI is simply terrible. Maintaining
> > the system (for 10-20 developers) is a headache too.
> > Your experience has obviously been different (this, frankly, amazes me),
> > but I would caution anyone thinking about PVCS to evaluate it _very_
> > thoroughly before taking the plunge and spending a lot of money on it. That
> > means borrow/buy just one copy and try and use it for all your normal
> > revision management procedures. Use it for at least a week and do your
> > builds with it. Then, if you like it, go ahead. My guess is that you won't.
> > > You get what you pay for, and if you don't pay anything...
> > I personally wouldn't pay _anything_ for PVCS.
> > Just my $0.02. The above opinions are not necessarily those of Araxis Ltd.
> > --
> > Daniel Neades
> > Araxis Ltd
> > Need visual file comparison and merging? Visit http://www.araxis.com and
> > get PMdiff.
> Well, we are using PVCS and it's not so bad. However, we don't use the
> GUI, only some commands as GET, PUT, VLOG, VCS. We just use the version
> control part of it, so we do not use it to build our software. We do not
> rebuild our software completely, but only in increments (e. g. we only
> supply changed components to our office branches), so propably our
> business is not typically. At least that way it works ok for us. I
> assume we could do much more sophisticated stuff with it, but we don't
> need it.
> Rudi Ziegaus
> Hypobank Germany
a few command line utilities. It's been pretty servicable for that. My
complaints have been minor: vdiff should have an option to ignore white
space like Gnu diff. It would be nice to have project-level control that
doesn't require the GUI. I'd also like to see some way to represent new
and deleted files in the revision archives, so that I can recover any
version without excess or missing files.
Currently I kluge the representation of deleted files by maintaining a
second archive directory tree containing my "obsolete" files. Whenever I
obsolete a file, I move its archive and reference copy to the obsolete
tree (a batch file does this) and add a delete entry to a REXX script
that is archived. When other programmers get new revisions from the
archives, they also pick up the REXX script and run it to flush the dead
stuff from their workfiles.
Another problem I ran into was that PVCS adds all EAs to the archive on
check-in, and this needlessly bloats an archive for a REXX script with
its tokenized form (stored in an EA). It's like adding the uncompressed
OBJ file to an archive everytime one checks in a C source. (The archive
for my obsolete script grew to several megabytes before I realized why I
was running out of disk space.) I wrote a post-put event handler to
strip the REXX-specific EAs from a file before check-in.