file management - best practice

[mmiles]

what is best way to "archive" or back-up versions of the project?

Our office tends to conduct weekly reviews of projects - which inevitably end up with Red-Lining, and re-working things. Since our office is relatively flat, in terms of heirarchy, many people end up single-handedly running their projects. The tendency in our office is to perform a save-as after each review - thus "marking" it in time. The result is that every project has dozens of files associated with it, and the minimum number of back-up files. of course the file naming must therefore include indicate the "mark" - which in our case, I've noticed, is the use of numerical date (i.e. 051509-Project Name-suffix). To me it seems over-board with the saving, since there are really so few times that we actually roll back to previous incarnations. I personally only perform the save-as when I reach a milestone, or end of phase (i.e. schematic design, or design development).

What is the intention of Revit with regard to managing the data base?
Are we being overly cautious?

[twiceroadsfool]

Our files never have any mention of date, or issue, or project phase, in the file name. This way, the file name NEVER changes, as the file proceeds throughout the entire lifespan of the project. Archives are done at milestones, and the model is COPIED in to the archive directory (and subsequently detached from central, and made its own central file, so it isnt opened as a local of the actual central.)

Im not sure why you would save a copy every week as changes happen. Did you do that in your AutoCAD workflow before?

Our file naming is based on a simple "Need to know" set of fields. What do you *technically* need to know to open a file?

Project Number-Discipline-Area Subset (if broken up in to links)- Version of Revit-W (suffix if worksharing is enabled).

209005-ARCH-AREA3-V10-W.rvt Is one example.
208207-ARCH-V09WU3.rvt Is another (Small project, one model, no worksets, on web release 3 of 2009).

[need4mospd]

At milestone issue dates we'll Detach from Central and save it to an archive folder on our server.

I avoid renaming files due to having to re-link them into other files if they are linked.

[mmiles]

Im not sure why you would save a copy every week as changes happen. Did you do that in your AutoCAD workflow before?

Yeah, I am not sure really. based on turn-over and being extra busy, our standards have become minimized. I haven't been using ACAD for a couple of years now, so my experience with these particular folks is based around Revit use. I practiced using a suffix to indicate what incarnation a dwg file is - (e.g. NAME-A,B,C...dwg). But we will copy a file to an archive folder whenever we reach a milestone.

Our convention for ACAD would be like this: project number- drawing type signifier- drawing number.
for example:
07027-A2.0.dwg
would indicate the 27th project in the year 2007,-Architectural Floor Plan-Lowest level plan.

In Revit, I modified the naming to be more like:
project number-ID of some kind (client name, or building name)-version of RAC-Phase
for example: 07027-PoolHouse-v2009-CD.

I can see why keeping the name unchanged (no phase indicator) would be a good idea. What I cannot figure out is why people feel compelled to become more liberal with naming conventions when using Revit (i.e. "Barn15.rvt"). It seems like naming conventions and other standards are being thrown out with learning "this new fangled program". Nor, can I understand the need to save-as so regularly. I suppose the argument is that if it is needed to pull last weeks work out to compare, it can be done. the problem I have, aside from the lack of consistency, is the number of files that accumulate on the server is growing larger and larger.

Is the idea of the journal file that we can roll back to an older version? Or, can the journal be used to selectively take older, disregarding work and revive it in a way that can be used to copy and paste into the (current) project file? How can I convince folks to stop making so many copies?

[twiceroadsfool]

Journals arent really going to help you get back to an earlier version... Theyre *technically* just an internal (internal autodesk) debugging tool (unless thats changed?) Theyre not really supported, etc. But, they wouldnt really do what you wanted either, without cutting and pieceing together fragments of everyones journal files. Let me ask you this: What did that office do BEFORE to get back to an older version? Ive seen a lot of firms get hung up on this going to revit, and im not sure why.

The central Files have Backups you can roll back too... How many depends on you. But as an aside, doesnt the office serve have backups? Save as at milestones, sure. I mean, even if you WANT to save a copy off every week, i guess more power to you as long as theyve got a ton of storage space to boot. But i wouldnt rename anything, and i wouldnt include the phase in the file name.

[mmiles]

I share your thoughts on this matter of what was done before Revit came about. That is partially why I am baffled to find all these extra files on our server. I am not sure why these folks are saving copies everytime they have a meeting. I guess they are trying to preserve the moment.

Personally, I just make revisions as needed and move on- save>file now updated to reflect revisions>same name, etc. Milestones get archived, but that is it.

Thanks for your input, Aaron. I was hoping to hear from others about naming conventions, and archival processes....oh well. I am sure if I put my mind to it, I can find more threads on this. My searching skills suck, so I get frustrated by finding nothing, or conversely all sorts of irrelevant things.

[Mike Sealander]

Matt and others:
I actually do a SaveAs for milestone iterations, but we have a small firm, so things are a little simpler. Our milestones aren't weekly. They are often the product of a significant client review. We've never had to roll back. Truth be told, milestone SaveAs events are a convenient way to reduce file size on a regular basis.

[twiceroadsfool]

Reducing the file size isnt doing much for you, when youre creating a duplicate of the file every week...

As for naming... Ours is quite simple. As i mentioned, its based on need-to-know information before opening the file. Here it is...

[joel.196524]

Why we save as so much? Fear!

My is a small firm and our revit files are not linked. You see, one single file can store all your work, and God for bit your file becomes corrupt (which happened to me once in 3 years) and let said that your last milestone/saved to backup was two weeks ago, you just lost two weeks of work. Revit is a pretty stable program but putting all your hard work into a single file - it is just scary. Trust nothing!

I save as like this: projec num-date-proj desc (so that the latest version is the last one) almost every two to three days. Then come back once a month or when the project is finish and delete all the extra files that were created along the way. To me it is cheaper to have a large storage (and multiple ones) than to wake up one day to find out that you lost two or more days of work. And that, is the true reason why some of us are save as FEARnatics. :-)

[Scott Womack]

Why we save as so much? Fear!
My is a small firm and our revit files are not linked. You see, one single file can store all your work, and God for bit your file becomes corrupt (which happened to me once in 3 years) and let said that your last milestone/saved to backup was two weeks ago, you just lost two weeks of work. Revit is a pretty stable program but putting all your hard work into a single file - it is just scary. Trust nothing!

If you are so concerned, then Activate Worksets, and use the Local - Central Files concept. This creates by default automatically a local on your machine, and a Central on the network. This is an automated redundancy. It then does not stop or prevent the "archiving" of a copy of the file. If you every need to open one of the archived files, you would simply click on the detach from central button, and save it as it's own central file.

[mmiles]

Scott,

Are you suggesting that a single user project should still activate worksets, for purposes of redundancy and archival? I guess I had not thought of the central file being a "kind of back-up".

Are there any pitfalls to practice, if a single user project is fairly typical (one half of all projects)?

[Scott Womack]

Personally, Yes. The only potential downside is a couple of seconds slower Save to Central (Syncronize with Central in 2010), and of course, the time it may take awhile to convert it the first time. This does provide for some additional methods of getting graphics to appear correct a little easier that embedding paramaters into items, since a View Filter can use a workset as an item to filter on.

[patricks]

In my experience, it is MUCH faster to work on a local file on your own machine and then STC back to the central file on the server. Otherwise, you're working on a file stored on the server, and save times are MUCH longer. When you STC you're only saving changes back to the central file. If you're just working on a file on the server, then the entire file has to be saved back across the network.

Most of our workshared project files take less than 30 seconds to STC, but a non-workshared file of comparable size, even one less than 20MB, can take over 2 minutes to save. And that's across a gigabit office network to a sever just on the other side of the wall from my PC.

So besides file redundancy, work speed and of course view control are some of the other benefits of worksharing a file, even if only one person works on it.