turning OFF wildfire versioning

I don't think its a possibility at all in pro-e without a serious software re-write on PTC's part.

Because pro-e opens the file once only, it doesn't tell the OS to 'lock' the file to other users/processes. Once the part is read into memory pro-e considers the matter done, and anyone else can do what they want with the model including deleting the file.

Along with this is the fact that pro-e considers this 'version number' more important than the time and date stamp of the file. This makes managing models in pro-e nearly impossible without some type of PDM.

st> hi all,

But, aside from the errant ways of Pro/GOOFY, there's the question of CVS and how it versions, revisions and releases. I'm betting that it ignores, because it has no knowledge of or does not take seriously, Pro/e's goofy file 'versioning' system. CVS is a program written for programmers, used in an environment where a lot of people are working on the same coding project, but different pieces of it. Since Pro/e's proprietary system of numbered extensions, indicating different, sequential versions of the same file, is not a commonplace in the programming world, I would guess that CVS has its own database and its own way of tracking version/revisions/releases through a more deliberate system than the accidental numbering of a file. That though would be determined by a more careful look into thier documentation.

BTW, Stinky, where'd you find these guys. Looks like they're worth a good look!

David Janes

? what do you mean ?

Basically we're an architecture firm and I implemented CVS in the office structure to keep goofy trainees accidentally erasing the project folder on the server. Now they can F up their own machine without being a liability.

Plus we lately moved to using laptops and CVS is perfect for satellite machines. CVS has a miriad of access methods, we use a locally mounted folder on a (freebsd) fileserver for the static workstations and a SSH access method for the laptops, our firewall tunnels th ssh port to the fileserver so I can access CVS from home without missing a beat. CVS is cross platform, so I can check out a copy in linux and in winXP (but don't try to use the same tree in both linux and windows, you have to check out a fresh copy per OS)

It works great for most of our work, but linked presentations (like indesign's), Revit and Proe need serious workarounds. For pro-e I mak a backup of the model in a temp dir (everything has a .1 extension), erase the contents of the dir in the repository (NOT the CVS dir) and copy the backup into it.

For windows there is a great util called "tortoiseCVS" which incorporates CVS into explorer. It colorises the icon to indicate whether you changed the file or not, shows the CVS version as a property, draws a revision graph etc.

I would seriously urge everybody to install it, create a local repository (a local dir on your harddrive) and test the hell out of it.

wzzl

"stinky wizzleteet" wrote in message news:40a32961$0$557$ snipped-for-privacy@news.xsall.nl... : : : It works great for most of our work, but linked presentations (like : indesign's), Revit and Proe need serious workarounds.

Okay, I think I get it now. It takes each file with a different numbered extension to be a completely separate file, not just another one in a series! So, it wouldn't automatically replace widget.prt.22 with widget.prt.31, apparently because it's parsing extensions and 31 makes it a different file from 22. So, if PTC had been smart enough to distinguish its files by naming them widget.22.prt and widget.31.prt, keeping the same extension, then CVS could tell they were different versions of the same file. And, wouldn't that have been much simpler, less confusing than adding the dorky numbered extension to the end of the file!?! How come I'm not the freaking millionaire! Oh, those crafty devils! I know why they didn't do it the simple and obvious way, so they could sell all 'the chumps', ahem, I mean 'the customers', the glorious solution to everything ~ the PLM software, like Intralink or Windchill. With PTC, it's always about sticking it to the users to make another buck. Man, I'm surprised they haven't had their asses hauled into court on a class action lawsuit.

: For pro-e I mak a backup of the model in a temp dir (everything has a .1 : extension), erase the contents of the dir in the repository (NOT the CVS : dir) and copy the backup into it. : : For windows there is a great util called "tortoiseCVS" which : incorporates CVS into explorer. It colorises the icon to indicate : whether you changed the file or not, shows the CVS version as a : property, draws a revision graph etc. : : I would seriously urge everybody to install it, create a local : repository (a local dir on your harddrive) and test the hell out of it. :

: : wzzl

I may be off base (an it has been several years since I used it) but was PTC was using a similar system to the VMS OS version numbering of files?

The cool thing with VMS was that you could 'hide' this versioning as needed. VMS also had a locking system so several users could work together and coordinate work done on a file(s). This functionality seems to be the 'missing link' in PTC's versioning system.

I used to use SourceSafe/SourceOffSite for version control of Pro/E files and ran into the same issue. My solution was to use Spekan Purge:

Spekan Purge has options to renumber the version to .1 or any number or to remove the version number altogether. I can't recall the details but I choose to renumber to .1. For one thing, that is less likely to confuse Pro/E users than removing the version number.

- Wallace