Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Is there a way to move imported files from doc to doc without creating a new version each time?
jacob_luetkemeyer
Member Posts: 8 ✭
I've got a compilation of DXF. Files in a document that I would like to organize into more documents. I've created new documents but whenever I try to move the files into the document it is mandatory to create a version. Each time I do this becomes a different versions which does not include the last uploads. How can I move my files into a documents main work-space?
Tagged:
0
Answers
I'm not sure I understand exactly what you're trying to achieve and what's wrong with having a new version.
But it's not that bad when you realize they're just time markers in history.
It bugged me too in the beginning, but now I just don't care.
Owen S.
HWM-Water Ltd
Using the version to describe what's going on, once you get to the release management "Revision" then it all becomes official, "REV 1"," REV 2"...
That way you have quick recall of all the changes along the way (able to see a little design intent), and once you release your "first generation" it has the first revision number.
Yes you'll probably have more versions than you would like but just name the relevant ones with a relevant name.
Here is how I name my versions (note I'm not using the release manager from Onshape, for now I prefer to do it manually):
Purchased component example:
Start --> Auto import --> V0.1 --> V0.2 --> V1.0
I consider always using the version 1.0 for purchased components.
In last example, when updating the document, existing version V1.0 would become V0.3 and I would create a new version named V1.0.
If the last version of a document isn't V1.0 but is V0.4 for example, it means the model is incomplete in its modeling or in its properties and should be completed before it is used in a real design..
Everybody knows here that V1.0 is always the latest completed version for purchased components.
Original content I design example:
Start --> DEV - 0.10 --> DEV - 0.11 --> R0 - Initial Release
If a DEV version is important (milestone), i will add a description like "DEV - 0.42 - Inverted layout".
Since we can rename an existing version, it happens that a version "R0 - Initial Release" is renamed to "DEV - 0.XX" if it never went out of our mechanical design department.
If it went out of our department, then a new "official" release is required.
Furthermore, a document can have many drawings. If we need to revise a drawing in an externally released document, the new version will be named like "Rev - 2019-01-04".
If it might help...
I'm thinking versions should be left as an engineering thing never seen by manufacturing or customers. Instead, using release management for outside of the engineering department.
One thing that I think is important, a point made by @philip_thomas, for snappy drawing response, always detail out a version of your design. When he introduced this, it sounded easy and I think it should be easy to implement but I think you'll need a separation of version & release.
@owen_sparks at least it's not release ZB, I know how you feel about those dead releases. It seems like a release should be tied to what has shipped out, not prototypes or development. I think our responsibilities as engineers is to identify what product our customer received and have the ability to retrieve this documentation. If I ship 3 products, all different, than I should be at release "C" working towards "D". Is this just the perfect world?
Versions are cheap, think of them as a 'commit' - like Bill says, they're just flags.
Revisions however, are a big deal - they represent the release of a part, assembly, drawing or blob element (any data). They affect just the things you are releasing (and not the whole document).
Yes there will likely be customizable schemes, but you can do it today by uploading a CSV file with (for example).
0.1, 0.2, 0.3, 0.4 (etc), R1.0, R1.1, R1.2, R1.3, R1.4 (etc), R2.0, R2.1 (etc) - When you're done with the development phase, just jump forwards to R1.0. The only rule is you cannot go backwards.
And yes, Bills advice is good - Drawings of versions are WAY faster to open (because we cache the state) - drawings of Work Spaces are regenerated on open.
In our case the development phase doesn't end, we'll release, then start on the next generation. Pre release are numeric then onto rev A at release. The development then goes back to numeric which is a mess. What's newer Rev 2 or Rev B?
I'm begging to form an opinion that there should be two revision parameters for users to populate. One for what I'll call "private" and the other "public".
Private would be numerical and include micro revisions. Think of it as the development branch. Example V2.345
Public would be one of these revisions mapped to a letter. So Rev A = Rev 2.345
Then there could be a bunch of private development revisions.
Once ready the next public Rev B would be mapped to the latest numeric private state, say Rev 4.111
This way we maintain tight Intermal control, but our customers don't think we're nuts...
Part of me thinks these public revisions should be able to be pointed to any private revision, and be moved to allow far last minute changes.
Add in something graphical, a bit like the current branching and we're cooking.
Owen S.
HWM-Water Ltd
I've had a look 2 months ago on the release management feature. There is a very interesting discussion on the topic here which shows many concerns about many aspects of release management. Obviously, release management is very different from a company to another. To make story short, it is much easier and versatile (KISS principle) for us to manually manage our releases, which is already what we do for years. We only release and revise drawings, not part or assembly.
My release management process in short?
Development (many versions) --> R0 - Initial Release --> Development or correction (versions) --> Rev [date]...
@billy2
Maybe I wasn't clear but we separate development versions (yellow) and official releases and revisions (green) as you can see on attached image of a robot tool. This way, I can rename a "released too soon release" (if it didn't went out of the mechanical design department) and it becomes just another development version. Probably the last 2 or 3 development versions (yellow) are previous "R0 - Initial Release" with slight modifications.
But..... Will you please explain your over all structure. Where's your top. I suspect a project lies in a folder and your documents are light not much in them. I think your structure would work really well if you spread things across many documents. I mean, a lot of documents. Many documents, may not be a bad thing.
I think a problem is that we tend to put too much in a document which kinda messes up versioning.
Am I on the right track?
We did in older system circa pdmworks:
development . 1, 2, 3, 4.....
release A
development A1, A2, A3, A4.....
release B
My thinking is to use versioning for internal engineering milestones, versioning & basic time stamping. To do this I'll have to spread out across many documents. Like Eric's doing. I tend to put everything in a document which messes up versioning.
Then, when I ship, things going outside for machining, purchasing or contract manufacturing; that's when I'll use release states. So a B is outside documentation which I control more tightly than versions. I feel versioning is kinda automatic and better suited for the R&D development and engineers. At the end of the day, I'm more concerned about outside documents circulating around the community. I believe engineers can knock out designs with versioning without much instruction but designers controlling released drawings & geometry, this needs more attention.
Hoping I could take an engineer's version, give it to a documentation guy so he could release it and manage a drawing, BOM & the associated geometry.
I'm thinking of a system that'll scale up across 10, 20, 30, 40 engineers and documentation guys.
Possibly using both versioning & releasing. Versioning is inside the engineering department while releasing is outside the department.
chart:
development 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17........... (versions)
release A B C . ...............(releases)
If you branched, which I will do, then release will have to reflective this
chart with branching:
development 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17 ........... (versions)
release main A B C . ...............(releases)
release branch 1 A1 B1 .............(branch 1 releases)
So this means that before I detail out a design, it needs to be versioned which creates an immutable state and my designer can get to work. This is compliant with the Philip rule.
I have no idea if this will work, as you can tell, I'm trying to figure this out.
What'd you guys think? What am I missing?
I think you're on the right track! But this is only my opinion. I started full time in Onshape in March 10 months ago and did a lot of mistakes on my first project, like way too large documents! Many (linked) documents is the solution to get speed and manageability in your projects. A document should contain a main assembly (or a part in some cases) which is complete by itself.
I agree with you, versions for development (less control) and releases for external use (more control) i.e. other departments, suppliers, customers, etc.
I never release in a branch. A branch is only for development.
Hope this help.