turning OFF wildfire versioning

hi all,

I don't want pro-e to do my versioning for me, so I can use it in a CVS
environment.

At this moment all of my efforts have been in vain, nobody seems to know
how to turn pro-e versioning off.

help is greatly appreciated

wzzl

 

: 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.
:
Makes it hell, doesn't it, when you do a backup to another directory and Pro/e
blythely resets all those numbered extensions to .1, thereby shooting itself
obligingly in the foot (big smile now, say cheese

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.
http://ftp.cvshome.org/release/stable/cvs-1.11.15/cederqvist-1.11.15.pdf

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.
http://www.tortoisecvs.org/


wzzl

 

:<snip>
:
: 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.
: http://www.tortoisecvs.org/
:
:
: wzzl

 

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:

http://www.spekan.nl/innotiv/index.php?mnu=dwnl&sub=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