During the early modeling phase of a project, as team members are busy creating new elements, there may not be much traffic conflict regarding worksharing. You’re creating something new, so there’s relatively little conflict with other users’ actions. Later on in the project development, things get a bit more complex. Now, small changes are happening everywhere, and all the default and/or added relationships between elements become more… tempermental. Users begin running into the warnings that advise them they can’t complete their action until “user “coworker” has released the element.” Another scenario – you make a series of updates, no conflict warnings, you sync back to the central file. A half-hour later, you pan back over your view, and – lo and behold! – those updates are right back to the WRONGness they were at the start of your day. What gives?
The common culprit:
…of these nasty hijinks is users’ lack of sufficient Reload(ing) Latest. The RL command draws into a local file all the current changes synced out from numerous users on the project team, and brings a lone local file up to date. I highly recommend to project teams to do frequent RLs – I like a minimum 3:1 RL:STC, myself. In other words, 3 RLs between each STC. For large modeling teams, they might consider the ratio to be even higher. Think about it – if there are 5 modelers, thats 4X the amount of activity/modification going on outside of each individual modeler’s local file. That’s a lot. If an individual local file goes too long without drawing in all those updates, they are a) certainly not responding to the latest and greatest data/geometry, b) not releasing all the elements they’ve been modifying, thereby blocking other user’s actions, and c) more likely to reach a “file out of date, cannot sync to central” crash. And you can imagine what that means. Heads will roll!
.
Now let’s consider the Perfect Storm:
…a relatively new modeling team, a crunch towards DD deadline, and a large model. I throw in that last factor, because the larger a model size gets, the more a newer team inherently resists syncing – they don’t like the ‘downtime’ of waiting for long sync periods, and so they just…. don’t. Here’s the scenario: a few of the modelers aren’t diligent with their RLs and STCs. They’re cranking away on deadline, so they’re heads-down buried in their own project tasks. Several on the team, however, are diligently syncing out lots of changes – shifts in plan, embedded data updates for advanced schedules. Here’s where the warning bells should alert! Because Revit’s worksharing process actively tracks physical tugs-of-war – I’m trying to move an element someone else has already borrowed – active conflicts are easy to notice. But now, we’ve got some users syncing diligently, thus borrowing elements left and right, but releasing them again with each sync. And remember, once released, Revit allows another user to modify it at will. Meanwhile, we have a few users who have toiled away in now outdated local files for hours. When those Johnny-come-latelys finally DO sync, they are pushing OLD DATA – old locations, old geometries, old embedded data – right back over the work of the diligent syncers. Chaos ensues.
.
How can this be prevented?
I highly recommend ALWAYS doing a RL prior to a sync. This makes sure that other user’s updates are pulled into your local BEFORE you push out your own changes. Also, increasing the frequency of RLs between your syncs makes sure that local files are up to date, incrementally, with the collective progression of the project. If the entire team is on board with this system, then no one would have old, outdated geometry or data to accidentally override work that had been done by others. Also, increased RLs mean shorter sync durations, because there isn’t as much out of sync to begin with. That means less queuing up of network traffic, less frustration over long waits, more efficient productivity. In short, happier campers… I mean, modelers.
.
Long story short:
…a few bad apples can spoil the pie. All it takes is for one team member to be a reluctant RL/STCer, and you’ve got the potential for old overwriting new. This isn’t really a Revit phenomenon, old data overwrites can happen in any program, but because Revit is an all-inclusive model environment, with lots of responsive interaction between elements, it’s repercussions are more, how shall we say?.. dramatic.
.
So get it implemented – RL early, RL often!
Woah! I’m really loving the template/theme of this website. It’s simple, yet effective. A lot of times it’s challenging to get that “perfect balance” between usability and visual appearance. I must say that you’ve done a great job with this. Also, the blog loads very quick for me on Chrome. Exceptional Blog!
Very Useful information, this is both good reading for, have quite a few good key points and I learn some new stuff from it too.Please sustain posting. Keep up the good work.
Pingback: Trackback