Architectural Drawing Revision Management

I am wondering if anyone has any advice for a good workflow for managing Architectural Drawing Revisions?

When starting the design process a client will have suggestions or want to see something different than the original design. I might be several versions into a drawing when the client might want to go back to something contained in a earlier version. I am currently only deleting old ideas when I know that they aren’t going anywhere.

Current process is heavy on tags and utilizing a new set of tags for all the things that are changing between revisions which creates a lot of tags and having to delete newly added tags from old revisions to keep them old.

I am wondering if each Revision should be nested under it’s own Revision Tag/Group.

Any advice would be appreciated.

Thank you!

I would save each design option as its own file. Packing them all into a single model file slows SketchUp down and then you have to make complicated tag and scene combinations to show the right things for each version.
In our parts, early design options are really not called revisions. Revisions are changes to the design done after construction has started. Usually there is no reason or possibility to take a revision back so these can usually be designed to the original file and then distributed with revision markings added to the documents. It is more important that he model file and documents from it are up to date than that changes are infinitely undoable.

4 Likes

If you save old versions as another file then you can later paste parts back into a new version of the main file.

1 Like

I’m a totally newer SU user, but in my workflow of only working on my own custom home I simply used a sequential file workflow of 1, 2, 3, etc. Then for any variations at any point I simply used decimal versioning (although using underscores) to differentiate. They do this in software development with major, minor, revision. So my files look like this.

HomeX_1_0.skp
HomeX_2_0.skp
HomeX_2_1.skp
HomeX_3_1.skp

Where you can see that revision 2 got a .1 change and then progressed on as 3_1. If the progression had been to 3_0 then the progression did not include the revision between 2_0 and 2_1.

For reference (but you don’t have to go to a level 3 necessarily)

2 Likes

Thanks for all the great feedback! I think I have been overcomplicating things a little bit. I think saving each revision as it’s own document will definitely clean things up and being able to copy and paste between versions will also be helpful.

Yeah I use multiple files, but i also have a common tag to all projects called Superseded which is where i place old but still relevant stuff.

Sketchup can import and entire file so you dont need to copy and paste the individual elements,just import the SKP model.

Trimble Connect can also load and compare two model versions if that sort of version/change management if what you’re after.

I use multiple techniques.

Versioning (V1.0, V1.1) has been mentioned. It’s saved my life when at least one file got corrupted and refused to open, as well as numerous times I’ve gone back to restore an object that the stupid SketchUp move bug destroyed with no undo.

Parallel files can be, but are not always the whole model. I have lots of scratch or work files that serve to work something out before placing it in the main file. For parallel files, Paste In Place is your friend for things to line right up.

Layers/Tags with alternate designs are common, but one note: Flextools is great for quick design, especially Schematic Design, but it doesn’t play well with alternate objects occupying the same space on hidden layers/tags; it’s cutting tools for windows and doors “sees” everything and gets confused trying to cut through them all.

Yep same as most here…

New version = new file -v1, -v2, -v3 etc

not all are issued to the client … they maybe be internal versions…

I also have two file folders in every project

IMPT = imported files [files received from anyone that remain untouched as a record of what was received…usually in a structured and dated subfolders eg. ELEC / 211034 (YYMMDD)
PS … these are never edited in this folder… if needed they are copied into a production folder and manipulated there.

EXPT = record of every file issued to anyone [most commonly in PDF format] again in structured subfolders by destination and date eg CLNT / 211112 Project v1 etc

Whist I use a versioning system, I tend to keep one ‘current’ model (jobnumber_current) and try out options in versions (jobnumber_20211222_opt01). The reason for this is that way I don’t have to keep changing the model reference in Layout, just update the existing reference to the current drawing, and deal with the updating in layout.
Once we move on to site I maintain an "as built’ model (jobnumber_20211222_asbuilt_rev01) as a ‘save as’ off the “current” model; if I am issuing details from SU via LO, then these are prepared in a new LO file referencing a bespoke SU file (with the relevant components copied in from the “current” SU file), and developed in this bespoke SU file.
It all becomes trickier when working with SU and Layout, and needs discipline.
Just a last note: we often undertake alterations to existing buildings, so we keep a separate set of “as_measured” SU and LO files, and generally start the design, demolition, and construction drawings off a copy of the “as_measured” file.

2 Likes

I’m with Jonathan on naming practice. Once I get into CD’s there is a certain name I use that is “blessed” and I can find that file by name years later. Only exception is major revisions of drawing sets after permit are marked REV 1 etc. It is the superseded versions that get a new designation, usually by date. I generally don’t change a SU file name though
My colleague on the other hand writes a date into every drawing file name (YYYY-MM-DD so it sorts by name.)

Also, the same here as many have posted.
We maintain saved files of SU and LO for archiving and reference as the project moves through project phases and revisions within phases.

Our revision tracking is based on the following Project Phases:
P0 - Programming
P1 - Pre-Design
P2 - Schematic
P3 - Design Development
P4 - Contract Documents
P5 - Bidding + Permit
P6 - Construction
P7 - Post Occupancy

And, then we then append a sequential Revision number:
ie: P3.00, P3.01, P3.02 & etc.
We also note this Phase/Revision number on our LO (printed) drawings for reference.

We also find as @gsharp notes, a folder with imported files and a second folder for exported files to be very helpful in keeping track of consultant/client exchanges.

1 Like

I keep my main model name something like this:

Client-JobName.skp

When I get an email or have a phone call to make changes I will then immediately do a ‘Save a copy’ and add the date:

Client-JobName-01-Jan-2022.skp

I keep working in the main file. The changes are always made to the file without a date, and the most current version is always the file without a date. Dates are added to a save as when large or complex changes are made and serve as a snapshot of the design process. But the work is always carried out in the file without a date.

If I’m deep into LO I will do the same to the LO file, but will link the appropriate copy of the SKP file and update before I save it.

I also have Rev# and Date on my LO files for easy communication with clients.

This keeps my working LO file clean, and updates automatically without having to re-link files.

If client says ‘I like the version we talked about on XXXDate - then I can locate and update accordingly.

1 Like

My folders are basically:

ClientName-JobName
Archive
Source Material
Final Stamped PDFs

Anything but the working models and LO files get put into the sub folders.

I like the way bmike work, it keeps the links with LO intact.

However in the beginning, I keep sketches as separated files like site, different buildings, some huge details. And import them later on when wanted, f.e when a building part, is more “This is the way”, then I copy/paste it in the main file. But every change got saved like bmike way.

I do that too, but how do you reference them to a particulate location or point in the main .skp fie? Do you create reference points somewhere?

I can see the logic in this. When SU crashes and offers me the cached version, I usually save that as another version number so the last saved version stays intact in case I need to return to it after all.

I keep experiencing a bug in LO where the link to he current SU file is broken, and the relink command doesn’t work. What does work is to relink to a previous version, and then immediately relink back to the right one.

All of the above are great solutions, the one I prefer however simplifies the number of files & scenes I am managing. What I do is have a working file for both my site and my building. these files have all of the scenes set up for plans elevations, sections etc. I name each of those per below; where “Project” is usually a short reference to the project lot number, client name etc:

X-Site_Project.skp
X-Building_Project.skp

The Building model itself, is contained in the working file as a component (important it’s a component, not a group). In the project folder where the working files are saved, I have a folder for references.
Because the building model is a component, It is easy enough to right click on it and “Save as” wile I am working. Especially in the early stages of a building when things change quickly I am able to work on several schemes/versions in one file. I save each building model version as:

R-SchemeA_Project.skp
R-SchemeB_Project.skp
R-SchemeC_Project.skp
etc…

Each of the building model components are saved-out as bare-naked SketchUp files. There are no scenes, unused tags, materials etc contained in each which keeps them efficient. All of the scenes are kept in order and contained in the X-Building working file. If I need to switch between versions, I can simply right click on the building model component and select “Reload” and I have the option to choose any other “R-Scheme.skp” file I like and as long as the insertion point is the same its a seamless transition. I do the same thing with the proposed grading/landscaping.

Each of these versions can be inserted and placed on a tag as well if I would like to save a version in the working model and just tab between them. As long as you are good about saving each one as you modify it it’s easy to keep a simple version history without having to update scenes, tags etc… if you need to switch to another version.

3 Likes