In past releases of Revit, prior to 2014, a linked file that is unloaded would get passed along to other users as they used SwC or Reload Latest, the file would be unloaded in their session too. It was a global effect, affecting everyone. In contrast using Reload on a linked file only affected the person doing the reload. Other users would not see the file as reloaded if they used Reload Latest or SwC. That meant Reloading a link was a local or personal change while Unloading a link was a Global change, affecting everyone.
As a result we started assigning individual linked files to their own worksets. This gave us discreet control over the unloading and loading of links through the workset dialog instead. Using Close and Open for a Workset is regarded as a local or personal change and doesn't spread out to other users on the team.
In 2014 I find that both Reloading and Unloading a link is now propagated to other users when using SwC or Reload Latest. They are now both global transactions.
This means it may not be necessary to bother with the Workset approach to manage the links now since it was originally put into practice as a workaround to avoid the reloading/unloading link "dance". By dance I mean, everyone gets a link unloaded and then we all end up trying to get the link reloaded each time we SwC or Reload Latest because someone else has unloaded it. This change doesn't eliminate the dance entirely. It just makes it easier to get the link re-established by one user so everyone else can see it again.
If you prefer to treat the unloading (and therefore the reloading) of a link as a personal or local change then the practice of one workset per link remains useful.
As a result we started assigning individual linked files to their own worksets. This gave us discreet control over the unloading and loading of links through the workset dialog instead. Using Close and Open for a Workset is regarded as a local or personal change and doesn't spread out to other users on the team.
In 2014 I find that both Reloading and Unloading a link is now propagated to other users when using SwC or Reload Latest. They are now both global transactions.
This means it may not be necessary to bother with the Workset approach to manage the links now since it was originally put into practice as a workaround to avoid the reloading/unloading link "dance". By dance I mean, everyone gets a link unloaded and then we all end up trying to get the link reloaded each time we SwC or Reload Latest because someone else has unloaded it. This change doesn't eliminate the dance entirely. It just makes it easier to get the link re-established by one user so everyone else can see it again.
If you prefer to treat the unloading (and therefore the reloading) of a link as a personal or local change then the practice of one workset per link remains useful.
4 comments:
Steve, I would argue that this change does not alter the best practice of using worksets to control links since what we really try to prevent is global unloading, which has not been affected. Worksets are still very useful to close out unnecessary links from memory, especially on large objects.
so we are noticing in our office that when one person uses Manage links and Manage worksets in a link that when they close a workset in a link and synch it passes to all other local files. PITB. guess we will have to break out point cloud into different models to unload per local file
J.Fout
Back-tracking these workset-per-link issues in 2017- trying to find out when/where they got started. Did some testing and the only benefit one gets is on controlled and limited lod of workset at startup. Other than that no benefit different from unloading link (FOr me or globally) in the session.
Hoping to come up with a more definitive workset nomenclature for multiply lined files and control of interrelated content across links.
This seems a carry over from a misused practice in CAD where links were put on layers to turn them on/off instead of layer 0 and on all the time - controlling through "-la,freeze,*RefName*|*"
The drawbacks - two more (compounded in links) locations where content can inadvertently hidden, and the complexity of keeping accidental content off those worksets, added back-checking required by BIM managers, etc.
Hope to see you guys as AU 2017!
Ron - I think I responded at RFO to a similar sounding post...
The unloading of a link in ML used to be All Users BUT the reloading was per user. The latter was the awful bit because this often resulted in a round the mulberry bush experience with users having to constantly reload links that someone else decided to unload.
The ONLY reason I still use a workset for each linked file is to get to decide which links I want to load during open. I spend a LOT LESS time waiting for files to open this way. Speaking for myself, I never was interested in this approach because of linked files in AutoCAD. For me it was always about trying to manage the user experience/performance (improve it hopefully).
I don't use V/G to display a workset either...okay maybe on rare occasions perhaps if it seems the easiest way to get something I want. If so, it is very rarely for a documentation purpose ... useful for modelling, to reveal elements I need to see to do something subtle, more easily.
Post a Comment