Results 1 to 5 of 5

Thread: Revit Build Number coordination

  1. #1
    Active Member hermeytheelf's Avatar
    Join Date
    2007-06
    Posts
    57
    Login to Give a bone
    0

    Default Revit Build Number coordination

    So I'm not super old-school but I have been using Revit since release 9.0. Over the years there are many things that have come into question about Revit that seem to be part of what I call Revit Mythology. The one that would be nice to put to rest is Build #'s!!!

    The way I learned it was that Revit would shoot tiny daggers from the keyboard at any one who was not on the same build as the rest of the team. Sooner rather than later, the Revit Model would mutate and implode moments later.

    The flip side of the coin seems to be the closest thing that we have ever gotten to a commitment on the matter from Autodesk...
    "I’ve researched this with development and support; we do not have a list of things that will happen in a mixed build environment. While mixing builds could in some cases cause problems, we have no specific cause/effect triggers related to mixing builds.

    In general, if everyone is on the same release, mixing builds should not cause problems. That being the case, there’s still a point to keep in mind - if a fix is released for a specific build, users on different builds won’t be able to benefit from the fix until they upgrade to the build for which the fix was created."

    Working for a really big company with dozens of offices with Revit users approaching 1K it would sure be easier to deploy Revit automatically. Take care of the whole company instead of one project team at a time.

    I would love to get more history and other peoples experience with this one. Especially since 2012 products are right around the corner.

  2. #2
    100 Club
    Join Date
    2006-04
    Location
    Calgary, Alberta
    Posts
    143
    Login to Give a bone
    0

    Default Re: Revit Build Number coordination

    We find it difficult to upgrade all workstations when a new build is released. Instead, we target individual projects and prioritize based on the content of the build.

    It is my understanding that the builds won't write a different RVT file so the team can work while on different builds. We try to avoid that but in a firm our size, people get shuffled between projects before we can finish installing the updates on the new project. So far, we haven't identified any issues related to different builds on the same project.

    We are looking for a deployment tool that will let us keep our Autodesk products up-to-date across the entire firm without taking down our network. We don't use GPO to install software. So, an update means we need to visit each workstation.

    What are others using to deploy updates to Autodesk software?

  3. #3
    Revit Forum Manager Steve_Stafford's Avatar
    Join Date
    2001-12
    Location
    Irvine, CA
    Posts
    7,567
    Login to Give a bone
    0

    Default Re: Revit Build Number coordination

    Short answer:

    A project team should be using the same build to work on shared project files. For example, an architecture team working on a "shell" project file and "interior/core/circulation" model (2 models) should all be using the same build. Anyone who is going to contribute to the project should be using the same build as the rest of the team.

    Stretching the short answer...

    Technically, you could have different builds deployed but avoid letting it happen within the same team. If a new person gets added to the team...pause and think about the build. Personally I think it would be nice if the software would mention that situation when a file is opened. In an earlier post on my blog I mentioned that David Baldachinno and David Kingham have written such a feature into their AutoHotKey Local File scripts. They've also shared their work here in another thread (I need to track them down).

    Think of it this way, they don't issue new builds because they feel like it or just because a couple months went by and they are restless. They issue them because they've fixed stuff, stuff that has been aggravating users enough to report them and press for fixes. They also fix stuff that they couldn't deal with prior to other releases or builds getting issued.

    When I use an old build while the rest of the team is using the new build my version can introduce a problem that the newer build fixes. When I get out of the project the rest of the team interacting with the project "fixes" what my build "broke". When I come back in and start using my build I can reintroduce the problem, starting the cycle over again. Much like passing a cold around the office "forever".

    At its most harmless...nothing happens and we never notice. At its worst we have local/central file corruption and problems. How severe depends on how big the fixes are in the newer build.

  4. #4
    Active Member hermeytheelf's Avatar
    Join Date
    2007-06
    Posts
    57
    Login to Give a bone
    0

    Default Re: Revit Build Number coordination

    Steve,
    Those are all really good points. I completely understand the need for new builds. There are always fixes to be had. I am also for everyone being on the same page with the same software configuration.

    Before getting deeper, some context is important to clarify...
    Last time I checked, we had 1322 computers scattered across a couple dozen offices in the company that have one or more installation of Revit. All three flavors and as far back as version 9.1.
    It is rare that we have a project that isn't being worked on by at least three different offices.
    Until very recently, all of the IT staff in the offices did not have common management, they were employed by the Office itself.

    Historically here at my company, what we have been concerned about more than anything is the scenario where Office A gets Revit updated and Office B does not. We have also been concerned that outside consultants whose detached models we link into ours will be one or two builds behind us. Because of this concern, we recommend that Revit be updated when a project needs it. Most IT staff do not understand this and most project teams don't talk to their IT staff and vice versa. As a result, teams don't get updates installed soon enough or not at all.

    Lately, the pain has been with people who are starting to work on Revit Server jobs. They need to get updated to the newest build and have the SAP installed. We have wrapped all of this into one script that will install it all. This is what we have done for at least a couple of years, the script will install Revit and extensions, hotfixes, external apps etc. It doesn't matter how easy it is and how clearly we point out in the instructions there are always IT staff who make the installation more difficult for themselves and the users. They ignore the install/update script and instead just run the update which of course does not install the Revit Server functionality.

    Whew.. sorry about that.

    The direction that I am leaning towards is to distribute updates via GPO and take the 'person' out of the equation. What I am struggling with is the fact that this is a rather draconian method of software update/installation and I am not familiar with what the pitfalls that may be associated with it are. The bottom line is that my primary concern is with the Revit users but the direction I take to change our policy may cause the workers to revolt!

  5. #5
    Revit Forum Manager Steve_Stafford's Avatar
    Join Date
    2001-12
    Location
    Irvine, CA
    Posts
    7,567
    Login to Give a bone
    0

    Default Re: Revit Build Number coordination

    Thinking out of the box, you need to simplify...break the big company up into little separate companies!

    Big firms definitely have it harder trying to keep this stuff sorted out! Small firms think you guys have it made because you can afford all those cool tools...you got those big IT budgets! Small firms don't appreciate how "lucky" they are.

Similar Threads

  1. 2014: Revit build number
    By MikeJarosz in forum Revit Architecture - General
    Replies: 4
    Last Post: 2015-01-16, 01:09 AM
  2. Autodesk Revit 7.0 - Build Number: 20050227_0414
    By cmahoney in forum Revit Architecture - General
    Replies: 6
    Last Post: 2005-03-02, 10:30 PM
  3. Autodesk Revit 7.0 - Build Number: 20050201_2130
    By cmahoney in forum Revit Architecture - General
    Replies: 4
    Last Post: 2005-02-17, 07:17 AM
  4. Build Number on Disks
    By mmodernc in forum Revit Architecture - General
    Replies: 1
    Last Post: 2004-12-12, 11:52 PM
  5. Build-Number
    By pwmsmith in forum Revit Architecture - General
    Replies: 1
    Last Post: 2004-02-02, 03:18 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •