What's new

Revision tracking - again!

NateLiquidGravity

Alibre Super User
Saving "snapshots" in time of the whole project like Lew does is one good way to make sure the previous revision doesn't get messed up later. For example constraints changing.
 

simonb65

Alibre Super User
I use CVS (free). Orginally used for my software development version control, but the fact you can use it with ANY file type, I now use it for everything including my Alibre CAD library and my Alibre projects. I tag the library and project folder (and its contents) at each project milestone and at every Alibre release.

Up shot is that I can roll my project back to a point in time or roll my library back to a specific AD version if newer versions cause issues to my parts.

Automatically backup the CVS repository every week and archive that away. Keep the last years worth of archives just to be on the safe side!

Revision control all my documents the same way. Works for me, never had issues and its flexability means I never loose ANY of my work due to corruption or loss as there is always a fairly recent version I can revert back to.

The key with any revision system is not the tool (and there are many CMS systems out there, from free to ££££££) ... but the process that you implement.
 

Hunter

Senior Member
In my mind, having a simple Project file (like Inventor has) for designs (which include models and drawings) will solve this problem, as JST also alluded to. It's still a manual process, but you can "uprev" the contents of a project, and keep the old/previous design. I used to work like this with Inventor, it takes a bit of planning and careful consideration of your filenames and revision control, but you can make it work very well.
 

simonb65

Alibre Super User
In my mind, having a simple Project file (like Inventor has) for designs (which include models and drawings) will solve this problem
+1

I like the idea of a project file rather than just treating parts, assemblies, BOMs and drawings as separate entities with no real context other than their own internal dependencies. A project file would also allow you to link and easily access other external documents associated with the design. i.e. datasheets for components, manuals, user guides, etc. or just associate parts, assemblies, documents, packaging, etc that aren't physically attached, but make up a single product, i.e. IKEA flatpack furniture.
 

bigseb

Alibre Super User
In my mind, having a simple Project file (like Inventor has) for designs (which include models and drawings) will solve this problem, as JST also alluded to. It's still a manual process, but you can "uprev" the contents of a project, and keep the old/previous design. I used to work like this with Inventor, it takes a bit of planning and careful consideration of your filenames and revision control, but you can make it work very well.
I also like this. Keeping it all together including BOMs and drawings would make thing a lot simpler.
 

swertel

Alibre Super User
I hear it - It's a complex issue and we've evaluated several PDM solutions that are either a) too expensive to include in a version of AD or b) way overkill and too complex to setup and administer and usually c) both

So we are left with doing something on our own, and it's bubbling to the top of the list. I think doing something here would be a good candidate for v24 or v25, so H1 to early H2 of 2021.
How does Siemens do it with the Solid Edge Built in Data Management? It runs via Windows Explorer, but with hints of a Sharepoint or database support. It's not complex, difficult to setup, or hard to administer. It's the same file/folder structure that we're used to, but with release statuses, link management, file moves and archiving.
 
You can leave them all in the same folder if you like. The revision suffix will keep them separated. Assembly files don't take up any space anyway.
Hi Sebastian -- But the advantage is that by creating a "Project Revision Archive" dataset, you can track and restore earlier versions swiftly & easily. -- Lew
 

bigseb

Alibre Super User
Hi Sebastian -- But the advantage is that by creating a "Project Revision Archive" dataset, you can track and restore earlier versions swiftly & easily. -- Lew
Same with my system. Since all the old files are all there too I can open which ever revision like.
 
Same with my system. Since all the old files are all there too I can open which ever revision like.
Hi Sebastian -- But the approach I use creates an archive record of every Alibre file, but all the "supporting documents" contained within a Project Directory Tree. -- Lew
 

simonb65

Alibre Super User
It ought not to be up to "Max and the team" to give us more than supporting tools as we can solve the "problem" with otherwise standard practices.
By that measure, why don't we all just revert back to a drawing board and pencil! Tools increase productivity, so use them to their max.
 

bigseb

Alibre Super User
By that measure, why don't we all just revert back to a drawing board and pencil! Tools increase productivity, so use them to their max.
I think Lew is referring to a methodology wrt how we name and save our files. To be perfectly honest, I took the time (years ago) to develop and fine-tune a method that suits my needs perfectly. I have explained it here on the forum and apparently some have found it helpful. I don't really need a new file management system. Sure, it would be nice but I would much rather have improved modelling tools.
 

JST

Alibre Super User
Our biggest issue is that the file, once named, is named forever..... not because you cannot edit, but because that instantly breaks all usages of the file.

If the "OS File name" was a "whatever" and the "viewable-within-the-program" or "real" file name were a field in the file, then it could be changed with no harm to the model. A nice feature would be a "free reader" or "library viewer" program that allowed viewing the internal filenames without use of the full program.

As I have said many times, look at just about any PC board layout program for a model of how this works. And it DOES work, well.

For those pure drafting applications, this is not as much of an issue,. You are issued a part number and official description before you start (or have a standard system) and you know just what the part is beforehand.

But for those of us doing design work, it is a real pain, because first, parts change character and require a different description or even part number (if one can even be assigned up front). The "washer" becomes a "seal", the bracket becomes a "support", the part number is assigned differently, etc, etc. One cannot foresee everything, and yet the system as it is assumes perfect vision and deadly accurate file naming systems, both ridiculous in client work and similarly ridiculous when you start with a "blank sheet design" for the product or portion of a product..

If it were not for the fact that they seem to be really quite serious, the people who assign such problems to "poor planning" and recommend "following standard procedure" would simply get gales of laughter. It makes the rest of us designers happy to turn over the files as-is for a complete redo, model rebuild, and rename session, done, of course, by "somebody else" (not us), who must make sure they are fixed and will "conform to naming conventions" etc, etc, at considerable avoidable cost to the company.
 

bigseb

Alibre Super User
But for those of us doing design work, it is a real pain, because first, parts change character and require a different description or even part number (if one can even be assigned up front). The "washer" becomes a "seal", the bracket becomes a "support", the part number is assigned differently, etc, etc. One cannot foresee everything, and yet the system as it is assumes perfect vision and deadly accurate file naming systems, both ridiculous in client work and similarly ridiculous when you start with a "blank sheet design" for the product or portion of a product..
My method involves making the file name a number. This can be an arbitrary number although I do actually have a system for this. The part name I enter into the description field. Then in BOM or drawing I call up the description as the part name. The file name (i.e. number) is separate from that. As a method it works well.
 

JST

Alibre Super User
That calls for a "yabbut"

Basically, "yabbut"...... eventually it has to have the real part number, and approved description.

Your method is fine for YOU. But it is unrelated to any client or employer system, which is where the problem arises.

The only visible name location is the OS filename, which is linked to the Alibre internal identifier. That means any change to the name requires the assembly to be rebuilt with parts etc having the approved file info.

A client, for instance, may not give out the required info until they see the parts as "real enough" to have their numbers assigned, and descriptors given. Then you get to "fix" it all for final delivery, which may mean a lot of rebuilding, or at the least, substitutions

Big waste of time. (Another) disincentive for a commercial outfit to use Alibre.

So, THAT is one reason for having the identification info NOT connected to the OS filename. There are undoubtedly many more, which is why the PC board design programs essentially NEVER use the OS filenames as human readable part identification. That all happens inside the program.

Note that having an internal name does not PREVENT a user from assigning an OS filename-based number etc. But it ALLOWS a different and (IMO) more flexible system.
 

NateLiquidGravity

Alibre Super User
Perhaps Alibre could and should develop a search algorithm into Alibre Design so that it handles things smarter. When a filename is changed that file can be found automatically when an assembly is opened.
Something like:
1. Search last know location for Alibre files of same type then check all of those for last known GUID.
2. If match found prompt user to verify this is ok, or a file to replace with, or to cancel.
3. If no match found then check deeper in folder tree.
4. If eventually no match found prompt user for a different folder to restart search, or a file to replace with, or to cancel.

It could also handle Window copies of things better:
1. If a duplicate GUID is discovered prompt the user with a selection between the two files (listing specs for both like file creation date, last modified date, filename, file path), or repair one with a new GUID, or cancel.
 

NateLiquidGravity

Alibre Super User
That's not to say we don't need an all encompassing project file. We still need that.

It is outrageous to expect a project with multiple subassemblies, and multiple unique parts (numbering in the hundreds) to be entirely detailed in a single drawing file. Projects with multiple drawing files are a must.
 

bigseb

Alibre Super User
(Another) disincentive for a commercial outfit to use Alibre.
That's the problem though, isn't it? Larger companies that require an in-depth file management system for their CAD are already using 'Big CAD'. There's no way they will ditch their current software vendor in favour of Alibre when Alibre still has so many other shortcomings and is a relative nobody. Big CAD like PTC, Autodesk, Dassault, etc have cornered that sector. Alibre have their own customer base: either hobbyists or smaller companies. So where would be the better place to invest in upgrades? A file management system that maybe only 5% of the user base want or improved modelling tools and a more robust CAD software?

Guys like me... I won't be doing work for Airbus or BMW or NASA anytime soon. And if I did it would something peripheral like a jig to spraypaint the wheel dustcaps or something equally mundane where there is no need for file management system. So I would much prefer tools that allow to design what I want in one software without having to resort to something else (like Moi for example). I get we might have different needs here but ultimately I reckon Alibre will cater to whatever sells more seats.
 
Top