Author Topic: Revision History  (Read 23441 times)

0 Members and 1 Guest are viewing this topic.

TR

  • Guest
Revision History
« Reply #45 on: January 10, 2005, 12:36:22 PM »
Quote from: CADaver
If it works for you, fine (as I told Hendie). Why I care is with the current boom in PetroChem, Pulp-Paper, and power distribution, we're pulling in all kinds of people from other companies and other industries to fill the gaps. Some of these guys are showing up with the mindset that every revision must be maintained. On projects with 25,000-40,000 drawings, that rely heavily on xrefs, that are revised an average of 4 times each, the maintenance of multple revisions would be cost prohibitive. If you'll read my original post, I was curious as to the thought processes behind the descision so that I could more easily explain to these new guys why we don't. If you'll read it closer, you'l notice my primary concern was adding the revision number to the file name, which is a real killer for xrefs.


If you read my original post you'll see I said get a document management system. You claim you have one but it must not be too good considering any document management system worth anything will handle the xref paths for you. I could take a drawing that's xrefed into 500 other drawings, rename it to ChiliCheeseFries.dwg and when I open a drawing that it was xrefed into it would still resolve.

The key to problem solving is not to teach not to do it but to make it impossible for the problem to happen. I've followed that philosophy for some time now and it's worked quite well for me.

CADaver

  • Guest
Revision History
« Reply #46 on: January 10, 2005, 12:47:55 PM »
Quote from: Tim Riley
If you read my original post you'll see I said get a document management system. You claim you have one but it must not be too good considering any document management system worth anything will handle the xref paths for you. I could take a drawing that's xrefed into 500 other drawings, rename it to ChiliCheeseFries.dwg and when I open a drawing that it was xrefed into it would still resolve.
Therein lies the problem.  If I'm saving the previous revision, I have to freeze the xref'd files at that point in time as well.  That would require a rename of the XREF as well as keeping th old name intact or, as I stated previously, a batch eTransmit function.  If you DMS, does either of these, pray-tell, please provide it's name.

Even if it does, that only solves my problem locally, and does nothing for files already transmitted to clients or suppliers.

TR

  • Guest
Revision History
« Reply #47 on: January 10, 2005, 01:06:04 PM »
I believe it does what you're talking about. No matter what we do to the files short of deleting them the XREF's always resolve. As far as transmiting them to a client it will fix all XREFs when you remove them from the vault.

http://www.cyco.com/ammeridian/

TR

  • Guest
Revision History
« Reply #48 on: January 10, 2005, 01:22:04 PM »
Here is a screenshot showing that Meridian handles the XREFS

http://www.theswamp.org/screens/tjr/xref-manager.png

CADaver

  • Guest
Revision History
« Reply #49 on: January 10, 2005, 01:28:07 PM »
We are currently using an older version of Meridian, and as far as I can tell, it does neither without a major interface from the manager.  We cannot, at least we haven't found a way yet, to have it manage maintaining the previous revision of both the files and the associated xrefs.  It will work on saving the previous revisions, but we haven't found a way of breaking it's link to the active xrefs and pathing to the previous revs xrefs without a major interface.  

Granted I didn't spend much (read any) effort in the exercise, in that I see no real benefit, but our IT guys kicked it around quite a bit.