My day job requires me to use PVCS Version Manager as our source code control system. The version we are using is a couple of years old (its the 6.8 release) and due to corporate security policies we are required to use the I-NET interface rather than the native Windows client. I-NET is essentially a Java applet which only works in Internet Explorer and provides very limited access to the PVCS Version Manager repository.
As a developer I have found PVCS Version Manager to be useless and a huge time sink. It is a horrible tool. Its retail price is more expensive then Perforce for a development team of 20 people. It lacks the most basic features. Its garbage and should be pulled from the market.
Developers can't be given the security rights necessary to create new files; consequently I have to write new code then send a bug report for each file to our configuration management team, who creates the file for me in the version control system. Ditto for deletes. This creates a headache for me if I send a bug report to have the file created but then find and fix a bug in the file before it has been added to Version Manager. (Given that the average turn-around on new file creation is 48 hours, this is rather common.) I have no idea which files I need to now check out of Version Manager to check in bug fixes and which files are OK as-is.
Did I mention this is even worse than it would appear as Version Manager offers no way to compare your working copy of the source code to a version in the repository? Sure it offers a single file difference between your working file and the repository version of the file, but what it can't do is give me the differences (if any) for all 8000+ files which make up our small product. Most of them don't typically have differences, but how do I know which ones have them if Version Manager can't tell me?
Did I mention that when another developer requests a file to be deleted from the repository and our configuration management team follows through with the bug report that was sent to them, Version Manager won't remove it from my working directory? Yea... what's up with that? It will happily leave all deleted content in my working directory until the cows come home, pigs fly, or I delete all source from my local machine and refetch it all from the version control system. I think we've lost some 100 man hours over the past 8 months to this problem alone.
Writing up the bug reports for file creations and file deletions is also a huge time sink. There's no automated process to do this, so developers are writing down on pen and paper the names of the files they are creating as they create them; then a week or so later writing out bug reports for each one and submitting them to the configuration management team. We've estimated most developers are spending about 30 minutes to an hour each week doing this activity. Over the span of 8 months this is 240 man hours (0.75 hours * 10 developers * 32 weeks).
We also can't have multiple developers editing the same files at the same time. If I'm adding a new constant at the bottom of a file and Bob is adding a new constant near the top of the file (at least 50+ lines from where I'm adding my new constant) I have to either wait for Bob to finish or make the change on my local system, then days later figure out my file is missing Bob's change and redo Bob's change manually. Between schedule slippage of developers having to wait for a file to be released for them to modify it, or wasted man-hours redoing work which had previously been done (but couldn't be automatically merged by Version Manager as it lacks this ability) each developer has lost ~30 minutes each week for 8 months. That's 160 man hours.
I've seen developers spend an entire day because they can't get their local working copy to compile anymore. This typically happens because they have a partial update from Version Manager. Typical example is the developer has modified file X.java (but hasn't checked in yet); another developer has modified A.java, B.java, C.java, ... E.java, and checked all of those files in. The changes in A-E are dependent on each other, but the dependencies aren't immediately obvious. The developer working on X.java realizes he also needs to modify E.java and checks it out for modification... now they have part of the A-E change, but not all of it, and suddenly they can't compile code anymore or test. Because they can't find out how their local directory differs from the version control tool they aren't willing to just delete the directory and start over (for fear of losing their change in X.java and having to start over from scratch). But they also can't find out that the change in E.java depends on A.java through D.java, as Version Manager can't tell them these files were modified at the same time. This has cost the project at least 8 hours of a developer's time once every couple of weeks over 8 months: 128 man hours.
By default Version Manager will set the modification date of source code files you are getting from the repository to be the modification date of the file when it was checked in by the last author. This is an [sarcastic]awesome feature[/sarcastic] when you are using Ant as a build tool, as Ant makes compilation decisions based on the *.java file being newer (has a later modification date) than the *.class file. If I compile A.java this morning, but Bob then checks in a new version of A.java which he wrote yesterday (and hasn't modified since) and I then get the new version from Version Manager, Ant won't recompile it as A.java is still older than A.class (the source has yesterday's date on it, while the class has today's date).
After discussing this with our local configuration management team they told me the Ant build system was broken; build systems which drive off modification dates on files can't be trusted for incremental builds and another solution should be used. In classic form they couldn't offer up any alternatives. I agree that file modification dates are problematic, but I've rarely had trouble when working only on a local filesystem (NFS without network time servers is a whole other story). Every other version control system that I've used in the past (except ClearCase) always sets the modification date of the source files to the date/time the file was gotten from the version control system, ensuring that a date/time based build system will recompile it properly. (ClearCase gets away with not doing so by providing ClearMake, a build process which drives off the version information stored by ClearCase.)
So given that I was forced to add an a task to Ant which compares file contents by MD5 checksum, then touches the files to move their modification date forward to the current date/time prior to running any other tasks (such as javac). This was 4 hours of development time wasted, and now our build process takes 5 minutes instead of 2 minutes. Given that I try to do about 10-15 builds per day I'm losing half an hour each day to waiting for the build process to update the file modification dates. Other developers are in the same boat.
Because we can't do any reasonable differencing to determine which files we need to write bug reports for configuration management to modify for us, I've had to add special Ant tasks which scan for all files which aren't read-only in a directory and copy them off to a holding area. The holding area serves as a place for the developer to run 'diff' from on the command line or from within the Eclipse IDE to determine what they need to send to our configuration management team. We've spent at least 1.5 person-days on this little set of scripts; 10 developers actively working with them (and producing on average 8 new holding areas per day - 1 per hour) has cost us nearly 20 GB of disk space on our file server. It has also entirely bypassed the security system of Version Manager, as now anyone with access to our file server can read the source code. (A wider user base has access to the file server than to PVCS Version Manager.)
With a (burdended) developer cost of ~$70/hour we're talking about $92,960 (1,328 man hours) of wasted developer resources. Unfortunately management doesn't see these hours as a real cost, but the project is 2 months behind right now. With 10 people working on the project we're behind by at least 1 month thanks to our choice of version control tools. That's just the last 8 months. We've had this tool for years.
Early on in this project we tried to branch our source code base. Version Manager can't handle branches. The vendor claims it can, but it really can't. Our local configuration management team was initially unable to setup a single branch of development properly. Developers were forced to spend a couple of weeks to get our configuration management team to correct the system; for the next couple of months we kept finding files which had been branched improperly. This likely cost us another 200 man hours between developers and configuration management: $14,000.
We could have purchased Perforce, ClearCase, BitKeeper, etc. for a fraction of the cost of the time we have thus far wasted, and we would have only been 1 month behind, not 2 (the other month loss is more likely due to a few ill-defined requirements which were incorrectly implemented early in the project). We can't ship this project late, we're contractally obligated to deliver it on time. If we don't our customer will face a major revenue loss at a time which it can least afford to have one.
I miss the days of CVS. CVS for all its warts just freaking works. It could have saved us nearly $100,000 in man-hours in the past 8 months, kept the project one month less behind sechdule, and saved a whole lotta frustration.
To the PVCS VM developers: Have you even freaking looked at CVS? Perforce? ClearCase? Aegis? I realize some of these products are commercial and may be difficult for you to do competitive analysis on, but CVS is the defacto standard in open source development and its under the GPL. So long as you aren't stealing source code from it it is perfectly acceptable to study. Now that Subversion, darcs, and GNU arch are all stable you might want to also look at those. Oh and don't forget about git, which the Linux kernel team wrote in 1 month because of the whole BitKeeper fiasco. And lets not forget about BitKeeper, which is currently (in my opinion) the best version control tool available on the market.
skip to main
|
skip to sidebar
Posts
Blog Archive
-
▼
2005
(
45
)
-
▼
June
(
26
)
- Flyfly: Why Did This Get Cancelled?
- I Need a ReplayTV Remote On My PowerBook
- IBM Turns to Open Source
- BeOS Lives Again
- The People Behind Family Guy
- Its Not a Googlewhack, But It's Close
- Red Vs Blue Season 3 = Good Comedy!
- Republican Party Telemarketing
- Is America Becoming a Fascist State?
- Reorganized Photos With iPhoto And MovableType
- Just Starting Red Vs Blue Season 3
- Apple is switching to x86
- Apple better not switch to x86!
- First post written in LaTeX
- Remind me never to eat at McDonald's again
- Going with latex2html Anyway
- Clothing for Chickens
- Google Sitemaps
- Why bother getting vendor support?
- Giving developers cheap computers
- The horrors of PVCS Version Manager
- Joel's Book Reviews
- So I'm no artist...
- What the hell is up with movie theaters anyway?
- Brown Bear Theater
- Joining the blog'osphere
-
▼
June
(
26
)
74 comments :
Amen to that brother! PVCS sucks majorly, any helpful documentation on the web, you must be joking!
CVS can be a pain, but it can be worked out and there are millions of resources for it.
Like you, I'm stuck with version 6.8, so can't even use the eclipse plugin, source control - IDE plugin = major pain in the ass!
But luckily I also get to use TrueChange, the 2nd most crappiest Source control software in the world..
All of the shortcomings you have pointed out are in fact shortcomings but they are misguided. I think your problem is the knowledge of your SCM team. I have been a CM for 8+ years and could fix everything you are encountering inside of a month. I have admin'd in clearcase, pvcs, cvs, harvest, and Vss. They are all good and all bad in separate aspects it just basically comes down to the knowledge and creative solutions of the support team.
Jeff - There is a lot of truth in what you are saying. Our CM team doesn't seem to want to address any issues, just keep things as they are. Unfortunately this is a larger organizational problem, as many teams are like this. It is a rather deep rooted problem. Just changing our CM lead would likely not improve the situtation very much.
PVCS VM isn't in and of itself a bad tool; but when compared to other solutions available it does seem rather limited. I'm actually glad this CM team isn't trying to deploy ClearCase - that would be a nightmare. PVCS VM may have given our team enough rope to hang the developers with; ClearCase would have given them not only the rope, but more than enough guns to shoot our feet off with too. :-(
From what you've described, your development environment completely ignores all of the basic fundamentals of team development using a SDLC approach. That's "System Development Life Cycle", for all you cowboys out there.
Where's your common repositories for compiled and tested code at the integration test level, the system test level, and the unit test level? If you've all got your own version of the code and your own personal builds, and you don't use the PVCS project hierarchy or version locking and branching (it does work) or access control etc. etc. then its no wonder you had problems.
Completely ignores? Quite so, but not entirely.
We have promotion groups on each individual archive. Individual archives are promoted into each testing level based on management approval. Once an archive has been promoted into a level a new build is generated and provided to the testing team.
Unfortunately since we are controlling revisioning at an individual file basis changes which span 4-5 files often are "torn apart", wherein 3 of the files are promoted, but the others aren't. This is primarily because the individual file promotions are done manuallly by people other than the development team. The developers however spend several hours each week trying to debug why the latest build for a level isn't working properly.
We try to use the PVCS project structure, but we can't rely on it as there's tons of projects which don't belong anymore just lying around. When files are deleted developers don't know they are going way and wind up having them still on disk. Etc.
We do lock revisions prior to making changes, but then nobody else can modify the archive while it is locked. The archive also can't be promoted while it is locked. So while we try to use locks to prevent concurrent modification of source, in practice it means at least 50% of the time you have changes in files but you must unlock them to let another developer make a 1 line patch, or let the "configuration management" team promote the archive into the next level of testing.
We also try to use PVCS branching, but our admins can't seem to setup the archives properly to do it. Half of the time a new archive isn't setup to deal with branching correctly and the developers are left to fend for themselves when they don't get the right version, or they lock the wrong revision and check in their changes into the wrong branch.
I think the post above by Jeff was correct: a huge problem in our organization isn't so much PVCS VM itself as our "change management" team actually being a "change prevention" team who doesn't manage anything. It may be possible to fix or work around all of the warts that we are dealing with in PVCS VM, but why when there are better tools on the market which don't require work arounds?
After using CVS for 11 years and moving to a govt. project that is forcing us to use PVCS I can not beleive that people actually PAY MONEY to use PVCS. If you ever want to "have some fun" try checking out the source code under UNIX using their PCLI utility. It is odd how something as simple as "getting the code" in CVS is so freaking screwed up under PVCS.
Our admin had tried to promote files using PCLI. It was going to take something like 5 hours to promote 800 files. Which is crazy. :mad:
I recently was able to automate the PVCS VM web interface. Fortunately the web client uses basic HTML forms to send commands to the server which made it possible to "automate" actions via JavaScript. Things which are easily scripted in CVS (like check in a new revision of 100 files with the same comment) takes 300 lines of JavaScript and a lot of CPU time for Internet Explorer. But at least I'm not doing it by hand anymore.
[...] Yeah, I know, I know. Fair enough. And as I suggested above, a conservative change-slowly,-if-at-all approach isn’t always a bad thing from a high-level management perspective. It’s the way it percolates down to the team level that I find more depressing. Ah well. Maybe I’m fooling myself and I’m just too much of a cowboy at heart. [...]
i completely agree. pvcs is HELL. last week was the first time i got my feet wet with the horrible system. there wasn't a a way to check if the source tree in my workstation was up-to-date with a single click of a button (how i miss eclipse's synchronize). but i'm stuck with it. i am too young and my voice is too small to be heard by the big boys. i'll just have to find a way to make things easier. it's their money they're wasting anyway.
spearce, your admin is doing it wrong. PCLI is very scriptable, and you should not be launching a copy of it for each file you are promoting. I can update 400 files in under a minute with my script. Try adding something like this to your pcli file
run -y label -v"$ADDCHANNEL $ADDLABEL" @itfiles.lst
then you can call it like this: pcli run -slabel.pcli
you have to fill in the variables of course
Hello,
For those of you who have worked with both PVCS and ClearCase, would you recommend one over the other?
My customer is trying to decide between the two. We use a very primitive version of PVCS here and the ops team
is not very good at using its features. Thanks.
After spending one week on this product, I have to agree it is piece of scrap! How can anyone pay for this thing.
Hi there, just read your comments. Most of your problems are down to the way you config management team has got PVCS set up, NOT down to the product! PVCS VM is perfectly capable of handling ALL of the issues you've highlighted... IF you set it up correctly! IMHO you need to have a long chat with your PVCS admin and explain exactly (a) what you find annoying about PVCS and (b) what you really want to achieve from a code management tool. I suspect you have a PVCS admin that doesn't undertstand the full capabilities of the tool, and has restricted it accordingly.
In short... don't blame the product, blame the admin!
Trust me, we use PVCS with over 200 developers using native GUI and the web browser interface, and have NO complaints... but then, we know what we're doing ;)
Amen I was just sending this mail to my team members. When I did PVCS sucks search on google
10 deadly sins of PVCS aka Dimensions aka Changeman aka Serena aka Merant:-
Executive Summary: PVCS aka ... should be thrown out of the site.
1. No parent workset for the item. I must always remember where the item comes from, when doing merge from my workset to the parent. For example workset BORISU contains items from TTFW, CMN and APP. I must be very cautious not to export items from BORISU to CMN that really belong to RS APP. The tool takes no responsibility here – and it should. It should automatically place items where they belong. The annoying part of it that you can mistake it easily and it goes unnoticed and the tool has no option to reverse the action.
2. Merge and compare tool is real horror. – Merge tool is the working horse of any CM tool. I would be really embarrassed by being member of Merant’s Merge development team. This tool only, makes PVCS irrelevant for serious work. Merge is inherently difficult task but using the tool like Merant merge makes it really painful. It is buggy, has incomprehensible and confusing GUI. The most annoying part of cause is trying to understand what window represents which part of merge process. (This is ancestor? No? Then where is it? And what is this funny window with lines?).
3. No directory/workset content management. Adding/Removing files are not easily traceable (you never know who made export/import into workset and when) which causes the situation where removed files are appearing a new after they were removed – which is very frustrating. To remove the file I must find all the items and remove it from every workset– why it is not done automatically? When doing merge by exporting all items into workset it is mandatory to run compare tool before in order not to insert already removed files. I expect from the tool to warn me that file was removed from the system event if do not run compare tool before the export and do it manually.
4. No transaction management in import/export/checkout/check in/.... Cannot cancel the action completely after it has begun. If you didn’t do baselines to do the workset snapshot before, you eat it. It has to be done by the tool automatically!
5. No partial merge in merge tool (which is itself is horror – see 2) - If you made changes to 200 files you must merge all of them at once. Yes, I know you can make it per directory but this is workaround. And what if files are in different, not easily grouped, directories?
6. All this PR CR “IN RESPONSE, AFFECTED” bullshit.
7. No simple updating worksets from baseline. When you want to downgrade to baseline you must remove all items and export them. I expect to be as simple as choosing baseline and aligning all items by revisions included in baseline. However it is impossible see 3.
8. No simple remaining of files, no linking to files,
9. No Integration with explorer. I expect checkout being as simple as right click in explorer window.
10. No group uploading files in PC Client – must use Web Client à two different clients???? Why for Christ’s sake?
Well I couldn’t stop!!!
11. No different management for sources and products. – causing incomprehensible version trees of Jar files.
12. No GUI automatic actions where it is a must.
When uploading items choosing design part by default (Yeah I know there’s no connection between file system and design parts but it should be!)
Suggesting lately used PR/CR – it is soooooo annoying do type them again and again.
13. Why any workset apart from general workset must contain more than one revision of the file? – It is confusing and unnecessary. All different revisions are scattered amongst different workset and their location is completely voluntary – what the purpose of it? - .
I think any other CM tool is worth a shot.
Hi Boris
I think you're slightly off the point - PVCS Dimensions has nothing to do with PVCS Version Manager, they are very different beasts. Also, Changeman is a Z/OS based product, and has nothing to do with UNIX/Windows, which is the area that Version Manager handles. Whilst I appreciate that you might have had a bad experience with PVCS Dimensions, your comments simply aren't relevant to a discussion on PVCS Version Manager (or, for that matter, Changeman ZMF).
Scoop. You have no idea what you are talking about. I am working with Changeman (aka PVCS aka Dimensions) version 9 on Windows.
Brois
YOU have no idea what you are talking about :) I am using PVCS Professional v8.1.0 (aka PVCS Version Manager). That's a different product from PVCS Dimensions. They are two different products sold by the same company. They work differently. Look on the vendor website:
Here is the link for PVCS Dimensions : http://www.serena.com/US/products/dimensions/index.aspx
Here is the link for PVCS Professional (aka PVCS Version Manager): http://www.serena.com/US/products/pvcs/pvcs-version-manager.aspx
Just to confuse matters, they USED to call their mainframe product... Changeman ZMF. They still do:
http://www.serena.com/US/products/zmf/index.aspx
They may be re-branding the entire suite to be called ChangeMan.
Both called PVCS. Both Serena.
We use Serena Dimensions 9.1.3 and I have previously used ClearCase/Clearquest. I honestly have to say that Dimensions is awkward to use at best. It is partly our misuse as an organization but even if we had the right lifecycles, etc... the tool just doesn't stand up to the Rational/IBM clearX suite. One of the major problems seems to be the lack of version control for the workset directory structure. Most software systems need to be slightly cognizant of the filesystem structure they are running in. Being able to re-arrange the workset directories at will without any version managment is a major shortcoming in my opinion. Besides that there are numerous annoyances and basic design flaws with Dimensions. Just off the top of my head...why do I have to drill down to a given design part each time I switch views in the web client? Can't the tool remember where I was in each view? What if I want to export a portion of a design part structure into a new product...etc...
Finally, you have to wonder why marketing keeps changing the name of the product...pcvs, Serena Dimensions, ChangeMan, etc... are they trying to hide the reputation?
Quote "...Finally, you have to wonder why marketing keeps changing the name of the product…pcvs, Serena Dimensions, ChangeMan, etc… are they trying to hide the reputation?..."
YES THEY ARE!!!!!
I'd have to agree with your evaluation of Dimensions, which is over-engineered. At the end of the day, I've always been a great believer in using the right SCM product for the environment you are working in, and ensuring you have the right support for that product. PVCS VM works fine for a lot of the companies I've been in, but they may have very different requirements from, say your company. Regardless of which product you go for, if you don't have a clearly defined process and support staff who know what they're doing, your SCM product will cause developers grief - its not simply a matter of saying, "this product is good, this product is bad". My advice to you would be make a list of what you want your SCM product to do, then go to your management and organise a review of what you have in place, citing improving developer productivity as the main benefit.
As for the Serena renames, I think that is just a rebranding because they have new owners, rather than anything more sinister - there are too many users who have successfully implement Dimensions and VM to lose the brand name.
Just my sixpence worth ;)
Coop,
Rebranding in this case is a another word for customer deceipt or simple fraud - you choose. I don't remember ClearCase changing their name when it was acquired by IBM.
PVCS suits fine the companies that don't use it. Regarding the alternatives it is not worth a penny.
Hi Boris
It's true that IBM didn't rebrand ClearCase, but that doesn't stop it being overpriced and overengineered. Still, people chose to use it, because it meets their needs, ditto PVCS. Just because you don't like a product, or can't make it work for you, doesn't stop the product working for everyone else.
Coop,
Instead of talking of some imaginary satisfied customer. Try to address some concrete points which I addressed before.
How about transaction management during export/import/upload/update....? Or maybe directory content change management? Or maybe comprehensible merge tool? Or maybe usable GUI? And why I cannot upload more than one item in raw via PC Client tool? It is just a small fraction of really annoying things that PVCS is full of.
Coop!
This one I really want you to explain. Why I cannot delete directory if it is empty but has subdirectories (which are also empty). I once spent an hour deleting subdirectories. Man this is really crosses my red lines of acceptable quality.
Hi Boris
I think if you went to Serena they would be happy to supply you with a list of satisfied customers. I can only speak for the sites where I have successfulyl implemented PVCS Version Manager and they are still using it.
Are your problems about with Dimensions, or PVCS Version Manager? It's difficult to comment if you're not specific.
I am talking about "Merant Serena Changeman Dimensions Desktop Client" which a year and a half ago was called PVCS.
http://lh6.google.com/borisusun/RVh8eBClABI/AAAAAAAAAA8/0XDL0siBnw8/pvcs_about.jpg
Our "change management" team has now decided that moving to Dimensions is the right product for us, without first doing requirements analysis.
Management has determined that our current process is sapping productivity and can be improved. So our change management lead is selling a 6 figure upgrade to Dimensions as the holy grail, with no analysis of what our current failings are and what functionality is actually needed to improve productivity. Arrrrrgh.
Let me guess Spearce. The ones who don't actually use the product are the ones who make a buying decisions.
That's always the case.
What's stupid is the ones making the purchasing decision aren't seeking feedback from the folks who will use it, like finding out what they need to do their job more effectively.
What's even dumber is our development team writes software for an in house user (~1000 of 'em). We are always asking them every day "what can we do in our software to save you time in your daily job". But we can't ask that of ourselves when purchasing software!
For a year we've complained that PVCS is crap and it makes us work where no work should be done at all. The response of management was quick. They added "Change Document" field mandatory when doing check out (I hope you now what I am talking about) because they said it will IMPROVE THE PROCESSES It turned it to complete disaster.
Our build manager together with CTO decided that in order "to train" us to work according to PROCESSES we are prohibited to advance the state of the task skipping all the stages (and we have 5 of them at least) - don't ask me why. So now when I want to check in something and mark "Change Document" as completed. I must do five times in a row Right Click->Advance to next state->Right Click->Advance to next state->... I proclaim this as the most stupid things I've done on regulary basis during my professional carrees as a developer.
Now I am trying to avoid the system as long as possible (just by removing files from read only) and postponing all PVCS staff to the D day, which ususally comes before major builds.
Arrrgh
What is coming over loud and clear is that the people who make the decisions have not done their homework, and asked the people who are going to be using the product what they think and - more importantly - what they WANT and NEED.
I have used several SCM systems on Windows and UNIX - SCCS, RCS, CVS, SVN, PVCS VM, PVCS Dimensions, ClearCase (LT and full strength, VSS and Perforce. You can make any of those toolsets work - IF they are the right toolsets for YOUR
company. Likewise, I have seen sites where people have invested huge sums of money on some of the above toolsets, and the end result is lost productivity and frustrated developers, because the people who make the decisions have not involved the people who will be using the products. We are selecting an SCM toolset for the comapny I am with at the mo, and I am making damn sure every developer gets to see and test the potential candidates before we make a choice.
It seems to me that rather than condemn any SCM toolset, you need to go back to your policy makers and point out the problems with the process. Have you done that, rather than criticise the product?
Coop.
Managers can be bad, but bad managers+PVCS is really a disaster. The points I addressed before have nothing to do with management.
Boris
As I've said, you can put the best toolset in the world in, but if that toolset is not right for your process/environment, then it will be disaster. Many sites are using PVCS Dimensions successfully. If the product is not working for you, instead of blaming the product, do something about it! I notice with interest that you haven't said whether you have spoekn to management about your concerns. Have you?
Firstly, just as I written before PVCS is the major theme of complaints to management. There's also a joke here that when planning the weakly development meating we must reserve half an hour for PVCS complaints.
Secondly ,frankly, do you think blaming the customers of the product is better strategy?
I don't know if they fixed that bug but in version 7 (not zero, not one, seven!!!) that uploading large enough number of files were crashing the system Actually the system was stuck and you have to wait for hours to figure it out. Once we have to upload approximately 2000 generated files at once. So we have to divide the files in chunks of 100 and upload it 20 times - quite annoying.
Now, Coop - what management has to do with these kind of bugs?
Hi Boris
Firstly, I've checked with some friends who have installed and maintain a PVCS Dimension site. I ran your complaints past them, and they said that the majority of the issues you ahve outlined are due to either the administrator of Dimensions restricting functionality, or to poor user education - both issues lie with management. If the toolset is setup so you can't use it properly, then it will come out poorly.
I notice that you still haven't answered my question. Have you addressed these concerns with your administrator, or your management? I keep returning to this as THAT is the root cause of your problem, not the toolset! Please e note that that is not just my opinion - other people in this forum have posted the same thing.
Are you going to keep bleating about how badly the toolset is setup (or indeed how bad your processes are, judging by the sound of it), or are you going to try and do something about it?
Coop.
Firstly of all please read carefully my comments where I at least twice metioned that management was presented with the problem for a long period of time.
Secondly - during this discussions, you were presented some real problems with of PVCS which are not connected to management, processes or build administrators. See the post of Spears himself, 5, 14, 34,23,24. I think in 14 I did my best to summarize though I think the list can be much longer.
If any of these points management can improve by improving processes I'd like to know.
Hi Boris
You're missing the point! Do your management and administrators KNOW and UNDERSTAND the problems you are having?
Coop,
To your question:- take any anwser you like YES and YES, NO and YES, NO and NO, YES and NO. The result will ultimately be the same - PVCS doesn't not stand up to standards of professional CM software and best management in the world will not make any better.
Hi Boris
I think we will have to agree to disagree on the root cause of the problem.
You think it's the toolset, which I think is a contributing factor.
I think your root problem goes deeper than PVCS; it sounds like you, your Admin and management team need to review your SCM process and toolset.
As for PVCS, I'm agree with you that it doesn't seem to be the best toolset for you. However, other sites make it work, and make it work very well. Nothing either you or I say is going to change that.
Have to agree that PVCS as CM software will suite fine the companies whose processes NEVER include:-
1. Renaming files.
2. Deleting directories.
4. Too much merging.
6. Uploading more than one file via one tool only.
7. Saving developers time by smooth integration with other tools as Explorer for example.
3. Completely canceling actions done by mistake in the middle of it.
As long as I do sometimes rename files - obviously the toolset was not chosen properly for me by arrogant management which never asked me whether I do that or not.
Hi Boris
I have PVCS VM 8.0.1 open in front of ME right now, and I'm going through your hitlist:
1. Renaming files - I can do that
2. Deleting directories - I can do that
4. Too much merging - I can merge any conflicts that occur. PVCS is only spotting the files/directories that need merging.
6. Uploading more than one file via one tool only - just done a test load of 100 files via the GUI, and added three new solutions via the Visual Studio IDE with no problems.
7. Saving developers time by smooth integration with other tools as Explorer for example - got me there ;) No integration with Explorer.
3. Completely canceling actions done by mistake in the middle of it - haven't hit that problem in 5 years of usage.
I've also run your probs past a friend who runs a Dimensions shop. Apart from the Explorer integration, he can happily do all the things you've documented.
I maintain that nearly all of your problems are due to the way you have Dimensions setup, which is an Administrative/managerial issue. However, as you are so set against the product (regardless of other peoples experiences), I don't believe there is any value in me trying to tell you otherwise.
Just as an aside, have you posted your comments at CM Crossroads? I think if you did, you would find many other users who are happily using VM and/or Dimensions (or any CM product, for that matter).
Finally we are getting constructive conversation.
I am talking about Serena-Changeman-Dimensions-9.1. Desktop Client 3.1.3.1. Can you please guide me where exactly you do renames.
Rename - pay attention when you doing rename you actually doing id change and not file name. You probably mean "change workset filename". But when you do that you change it only in private workset. You cannot import the item in any workset workset until you remove MANUALLY the item from their main workset. This complicates merges - cause we basically just import all items from developers workset into main workset and then resolve conflicts.
The meaning of "cancelling in the middle" - is transactions support. It is not only that you cannot cancel actions in PVCS, you also cannot revert the changes during import/export/upload you made by mistake (CVS majorly sucks because of this too).
Deleting directories - You cannot delete directory if there subdirectories in it - even if they empty. If you can please guide me how.
Merge - I didn't say there' no merge capabilities. But the merge tool itself is a disaster.
Thanks.
Hi Boris
The best place to find the answers for your questions is CM Crossroads; for example, on the rename query,
look here:
http://www.cmcrossroads.com/component/option,com_smf/Itemid,180/topic,69950.0
You can post any questions you like or discuss features (or the lack of them!) on the forums. I know for a fact that the vendors regularly trawl the forums looking for issues.
Hope this helps!
And on the directory delete, try this:
http://www.cmcrossroads.com/component/option,com_smf/Itemid,180/topic,69020.0
It seems you're not the only one who has had this prob ;) Still, there is a way round it.
First of all thanks for the link. Though we have a "competenet" build manager it still will be useful for me.
However have you noticed that they agreed (in discussion room you gave me link to) during the discussion that you have to run away from Dimensions? :)
Check this out http://www.cmcrossroads.com/component/option,com_smf/Itemid,180/topic,69020.msg72052#msg72052
Anyway why should I have workarounds for such a basic thing? Something is rotten in the state of Denmark.
The fact that nothing is perfect doesn't mean something is not better than the other. You have to make right choices. It is really diffcult to imagine what kind of project PVCS is a best choice around.
I am very fond of ClearCase, though I worked with it when it sill belonged to Rational never seen it after. I worked with CVS+Tortoise and Subversion + TotoiseSVN - it seams to be fail safe choice - simple and usable enough not to drive you mad. I keep hearing that Perforce is really cool product though never seen it. Continuus sucks - (worked with it for a year) .
We installed new version of PVCS (10 patch 1) and it sucks more than ever!!!!!!!!!!!!!!!!!!!!!!!!!!!! Shame Shame on pvcs development team!
I tend to agree with Coop about using the right tool for the right application and the potential issue with the PVCS admin (very likely). Even Clearcase can be a mess if there is no good admin for it. However, like many other said, is the tool so EASY/LESS MANUAL WORK to use that everyone in your team knows how to use it, or it is good because everyone in your team is good enough to work around any potential issue? Or you build your own customized inteface tool to shield everyone from "screwing" up things? I just started to use PVCS (not voluntarily of course), and the concept of code promoted from one active branch to the "root" will affect the rest of the active branches (like branching is not really branching), and the whole work-around required on adding/deleting files really puzzles me. And I also see other problems that require MANUAL work as well. Of course, it could be due to my limited knowledge of PVCS. The funny thing, within the same timeframe, I don't have this issue when I look at the Clearcase version tree, as well as the EASY, STRAIGHTFORWARD commands that come with it. In my personal opinion, tools should be easy and straightforward to use and requires less workaround. I have no interest in proving myself about solving PVCS creatively, nor I want my developers to. It is always about how it helps us as easily as possible. Anyway, I guess to really understand why you like it, what is the nature of your team? Do you guys have:
1) Many projects within the team
2) A project with many active branches
3) How many files within a project
4) Are files constantly updated, deleted, and added, refactored?
5) Are there a lot of dependencies between each file?
6) Do you have lib or jar files that are constantly upgraded within different branches?
Any input will be greatly appreciated.
If all points you ask of, are relevant to your team than run away from PVCS as fast as you can.
Coop,
I like PVCS a lot. I know some people they just would like to put down what they don't know. I have used ClearCase recently, and I tell you, it might be a powerful tool, but it is very cumbersome to manage and adminster. To set it up, it took us over a year to get it to be installed on unix, and 9 months to get it installed on windows. The config spec is very confusing, and you can make many mistakes with that. On the other hand, PVCS VM can be easily setup with the File Server option which provides you easily with capability of accessing it from unix or windows. In a day, I was able to set up PVCS to be accessed on Unix and Windows without the need to purchase an interop solution. Try to do that with ClearCase.
I am sure if you have been using clearCase for 5 years or more, and haven't used any other tool, then you have tunnel vision, and lack exposure. May be once ClearCase is setup, and you have been using it for many years as a developer, then you might like it. We were having issues with ClearCase all the times. I am so glad I am away from that environment for now. I would say keep an open eye.
Coop, you wrote the following before about PVCS:
4. Too much merging - I can merge any conflicts that occur. PVCS is only spotting the files/directories that need merging.
This indicates to me that you can merge all files on branch to a trunk. Serena support informed me that is not possible!!! you can only do it one file at a time!!! can you please share with me how you merge branched files to the trunk (mass merge), like ClearCase? That is onething I know clearCase does well.
Thanks
How many active branches can PVCS support sensibly?
Boris I'm not certain at this point that you would be satisfied with ANY commercial version control system. Thanks for the drama though, good read.
Monarch,
I am very satisfied with perforce - very cool product, and I liked the subversion. ClearCase may be my third choice however I am well aware that it is overpriced and well too "big".
I get the feeling the pvcs development team is astroturfing here. pvcs has been an utter disaster on our project. we consistently get out of memory when doing a "get" on the entire repository with the GUI. no way to to "get latest" without downloading all files. can't promote a file while it is checked out. GUI routinely crashes. workspaces disappear at times -- unexplicately. impossibly slow. doesn't work over vpn with domain authentication. I could go on and on. and our experience is consistent with other teams. I can't imagine anyone is buying this software anymore. hopefully it will just disappear over time for the good of humanity.
Frank
I am amazed someone still uses it.
http://www.earth.li/~noodles/pvcs-sucks.html
Where I work, we have Dimensions 9.x (not sure of exact point release; either 9.0 or 9.1 I think).
Our small development team (9 dev, plus tech mgr, and part-time PM) have been using CVS for about 10 yrs
even though the company IT's "official" tool of choice is Dimensions. They let us get away with using
Dimensions for only release mgmt as long as we place a gzipped tarball into Dimensions for each release.
Several of us on team are dinosaurs in the sense we prefer a code text editor (e.g., vim, emacs)
and *nix shell over IDEs, but our tech mgr has "decreed" that from henceforth we shall convert everything
to Dimensions and no longer use CVS.
Can anyone comment on whether any of these problems with Dimenions mentioned in this blog are still
present in release 9.x? If there are still such issues, our mgr may listen to such things. I already
know that Dimensions is very convoluted (to say the least), but figure much of that can be addressed
with appropriate shell wrappers. But I don't want to also have to try to make up for it's shortcomings
of the sort pointed out in this blog. It might be better just to change companies.
-kevin
Years after still good reading :)
http://maillist.perforce.com/pipermail/perforce-user/2007-March/021177.html
A lot has been said about the shortcomings of Dimensions and the shortcomings of the development teams using it. I think both points are valid. I would rather have a knowledgeable CM staff than the best CM tool on the market but the tool quality does make a big difference. In fact, you could say that the lower the quality of the tools the more knowledge is required of the developers to use/workaround it properly. I think Dimensions could be used to provide rudimentary change management but the amount of expertise required to institutionalize the use of Dimensions is such that most teams will realize the need for a better tool before they would choose to make Dimensions work.
It has been very encouraging reading many of these posts because I work with a group of people who know that Dimensions sucks but don't quite know why. I'm glad somebody is documenting the why for us all.
2009, Dimensions 10. still sucks. :( The fundamentals of the product are unsound. It's possibly great for managers, but for a developer's day to day work it's generally a hinderance, taking more than a comparable SCM to tweak in order for it to be decently usable.
ClearCase is only as big as you want to make it. If it takes a long time to deploy it is because your admins simply don't understand it. I have been a ClearCase admin for a few years now and I can get a team up and running in less than a day - usually a few hours.
Tony mentioned config specs being difficult. Not sure what to say there as I've never had any issues but then developers today don't use make or ant files much either. They just want a GUI to tell them what to do... If you are really afraid of config specs simply use a snapshot view much like CVS or Subversion.
And yes, PVCS/Version Manager is still quite horrid.
Our company has used Dimensions 8.x and 9.x. We are thinking of migrating to Subversion. Has anyone migrated from Dimensions to Subversion?
Great review. This is by far the best PVCS manual ever written.
I HATE THIS TOOL
I've been a S/W Configuration Manager for about as long as Software CM has existed, and over that time I have used/touched/demod about every VC tool in existence for just about every platform in existence. I have been forced to use PVCS VM for about half of my career and I can tell you that it is absolutely the worst tool that actually costs money. I have been challenged by more than one developer over the years who refused to believe that some of PVCS VM's horrendous limitations really exist.
For those of you who are stuck with it (as I am right now), I strongly suggest writing as much code as you can in the way of triggers to beef it up. Keep whispering "SubVersion is free" in your boss' ear when time comes to pay for maintenance......
I can tell you how I fixed PVCS... I used the CVS server installed on our Red Hat machine to house and diff the code on a regular basis. I tag it during promotions, export the tag.. and check that into PVCS . The rest of my team just uses the CVS machine. Minimizing the pain is the only way I can use that POS system.
Far easier to just use the cvs server already installed on the machine than to beg for admins and bug tickets to be opened to fix it (if it can be fixed, I don't think most of it even can be). Everyone on my team has saved at least 5 hours a week for the last year by using an old version of CVS instead of PVCS.
I am amazed this thread is still alive.
Yup, worst tool ever. The only method available to me to use PVCS is through their web service as well. I have had to manually track what files I touch and change so that I don't miss one when I commit it to the server. God forbid another developer changes the same file I am working on and I have to merge the files. *gasp*
Git to the rescue!
I'm from a ClearCase background, recently joined a project and have to adapt to PVCS. It's reality, I've accepted it. Any advice? Is there any way to manage branches and labels like "Label Type's" and "Branch Type's" like ClearCase does?
Please help.
PVCS? Have features like ClearCase? Not really.
You can work with Branches and Labels(Version Labels) on PVCS. :)
Even WORSE than PVCS is Serena Dimensions (AKA Dumbensions or Dementians). We're forced to use the web client because of our pinheaded management. This is the slowest POS I've ever used in my life. Think of a skeleton sitting in a chair while Dumbensions goes ca-chunka-chunka-chunka. I was happier with PVCS if that's possible...
Just to let you know I still have to deal with PVCS. The company has been using it for ages, and only now started to say it 'will migrate' to SVN some time soon.
My stress level skyrocketed when I had to start dealing with PVCS, especially due to the lack of repository-level diff tools.
I ended up using a parallel Git repository, where I actually maintain my files, and only upload to PVCS when I'm done here. This has restored the sanity to me and my team.
:))))
Our organization uses Serena PVCS for 10+ years now.
We are currently using... version 8 planning to migrate to... Dimensions.
The project I work on, is mainly integrating code from other teams and after a "Z" team delivery integration, I have ~500 changed files (from ~2500), removed ~50 and added ~50 new.
With a some batch files and pcli scripts, I was able to automate this process, to require only about 10 minutes batch file configuration.
Now our management requires that we use links between the different builds we support (for reasons mystical and unknown to mere integrators). As our baseline labels are different for the different builds (which have hard links between them), I cannot use the scripts anymore.
I cannot honestly believe that someone has made the choice to use PVCS after objective evaluation of its "features".
Post a Comment