Monday, January 30, 2012

Revit and Drop Box

In the context of Revit and Worksharing (central and local files) and using Drop Box.
    Suggestion #1 - Please don't
    Suggestion #2 - If you ignore suggestion #1 please be careful and don't get mad when things go badly.
I wrote about an experiment using Drop Box with Revit back in June 2010. Though it technically worked, in my opinion it isn't suitable for a real project with people working concurrently. Why? Because Revit makes element borrowing so easy that someone will inevitably borrow something subtle like a tag or text or a view setting and then not be able to synchronize any of their work.

Companies like Riverbed exist, and it's taken a lot of effort at Autodesk to develop Revit Server, because data integrity (Bits and Bytes/data transfer/latency) between Central and Local files (element permissions) is not trivial. Drop Box (I really like it btw) is really just copying files from one place to many places. It does it quickly but not quick enough for concurrent activity...not all the time, every time, never fail. It does nothing to manage Revit permissions and that's what will burn you, borrowing something at the same time as another person. It comes down to what sort of gambler you are. Comfortable with losing 10,20...30 minutes works?

There is hope...IF you are extremely competent with Revit...AND...the kind of person whose pen and pencils are arranged in a very specific order on your desk and can tell if someone touched your work area in some barely perceptible way...AND...the other person(s) you are going to try this with is your twin in this way...you might be able to pull it off. Might help if you are going about it as if you are playing Halo (WoW or COD) online and communicating (via a headset) with the other person continuously as you work.

It works great to share a project file if you and your teammate are "following the sun", you start working on it when they've finished for the day. The real danger is concurrency, doing stuff at the same time and the very real risk of borrowing the same thing at the same time.

I know there are people that have done this and have had success. There are exceptions to every "rule". There is a thread at RevitForum.org and post this morning at The Revit Kid advocating it works. What I'm most concerned about is people diving into a real project and having a go, then dealing with hours of work that can't be reconciled because they weren't prepared enough for the worst.

As I wrote at the beginning, if you ignore #1, don't be upset with #2. You've been warned. Be careful out there!

12 comments:

Fred Blome said...

Steve - nicely put. I was hoping that anybody trying this setup would be aware of the risk but repeating the caution was good. It only takes one small "oops" mistake and somebody has lost work.

Fred

Anonymous said...

if only revit would move to a true database platform instead of a file with permisions.
Syncing over VPN event with revit server takes forever.

Steve said...

The "parametric change engine" means that records in a database are not just individuals co-existing without regard for one another.

Most traditional database activities, people filling out forms and such, are not highly competitive or linear transactions where there up and down stream dependencies.

If it were simple...it would already be so.

Blue Jay said...

As usual, great post. Thanks for the clarification. Anyone you know using Globalscape? Just had a client say they're planning on using it over Revit server. They don't like the fact that Revit Server needs a continuous internet connection.

Steve said...

Jay, I've written about them before as well as met and/or spoken with several companies that were quite pleased with Globalscape's solution.

I'm out of touch with them lately so I don't know where things stand today. Unless they've lost interest in serving this niche...should still be capable?

Anonymous said...

steve,
It is already so. Graphisoft implemented a database file structure. Syncing and managing permissions is years ahead of Revit.

Steve said...

The products aren't apples and apples internally. One technical solution based on another product doesn't mean that it would "just work" on another.

Anonymous said...

There is nothing special about Revit that would preclude it from working as a relational database structure instead of a shared file. In fact while a don't really agree with the emphasis on a constraint based parametric model, even constraints pose no obstacle to the database structure.

Steve said...

I guess I'll have to take your word for it. I've never seen under the hood of Revit so to speak. I've been under the impression that it is already a relational database. It exports data to ODBC format readily and generates a relational DB in that format.

Guy said...

There is something special about Revit's internal design. Revit is not a constraint based parametric solution. Fundamentally it models relationships. Revit at it's core is an object database. This presents considerable issues when looking at asynchronous operations. Whether it be model sharing or scaling for CPU cores.At the same time Revit's core design presents considerable advantages both for users and in comparison with any competitors.

Anonymous said...

I'm actually considering this method for an upcoming 12-unit apartment building. The two halves of the design team are 300 miles apart. Our plan would be to NOT work concurrently but still use worksharing to maintain a current working file. I suppose the same could be done without worksharing but it might be worth the experiment in any event.

Thanks for the write-up and links!

Steve said...

Sounds like your situation fits the risk profile much better, good luck with the project!