I have a software engineer for a boss that is managing all of our data (AutoCad files, firmware files, etc.) on a freeware versioning manager named TortoiseSVN.
I have my doubts but am curious to hear if you have any experience with it.
We have had several customers ask about using TortoiseSVN/Subverision with in EPDM, and I have found that it is a kind of redundant for software files. I use it myself to control software I write for our customers and use it with our own EPDM vault. (That is the trunk's are located in our vault). As a stand alone programmer it seems to work well with EPDM. However, I would not recommend it for groups of collaborative programmers.
However, you bring up an interesting idea about using TortoiseSVN as a SW file manager. I'll give that a try and let you know.
Subversion (SVN), CVS and the likes are great for text files (source code, etc), allowing you to merge and update using changes made by several different people. This is why programmers use such tools.
While binary files can be stored in such systems, there is very little benefit in doing so. Most of the fancy features that work for text files aren't usable for binary files.
Okay. I have to agree with Jim. I tried a few simple things like modifing a simple part and it was slow, Tortoise crashed, and just not as useful as a data management system that is designed for SW because all the interface was outside of SWs.
What concerns me is losing associativity between assembly and part files, and losing it between parts and drawings.
I can see a setup with SVN where I have a SolidWorks directory containing all things SolidWorks with subdirectories broken out into common toolbox type parts, assembly files, released drawings and parts, etc.
As you know SW is looking via search path for the most recent files to pull into an assembly, and also has those files tagged with an internal i.d..
The way we're using SVN right now with 2d AutoCad type files is to "checkout" an entire directory to a working copy directory on our desktop, make changes, and "commit" them back to SVN. If I need to update an assembly file that uses some common parts in a toolbox that is a couple directories down in SVN, I fear I'll have to checkout all of that stuff out to my desktop and create a big working copy mess.
It's the associative linking that I fear messing up.
Comments...? BTW, we do not have any sort of an EPDM system and that is what he/we are trying to accomplish with SVN.
We use tortoise SVN here and havent had any major issues with it. I'm no expert on the entire SVN system but it has worked well for us. The issues I've had with it are similar to your worries. For example, when we send something out for production we branch/tag our files and place these into a revisions folder. However, if you needed to open a drawing of a previous revision chances are the references in the drawing are pointing to the working copy. In this case we have to then update the reference parts location which can become tedious. The best use of SVN for us has been for a common toolbox like you described.
Also, if you were asking about checking out an entire directory, you can check out individual directories using the repository browser rather than checking out the entire repository above a subdirectory.
Apologies for the thread resurrection, but this seems to be the only one dealing with Subversion.
Brett, when you were looking at previous design revisions did you try rolling back your SVN working copy to the relevant SVN revision number, rather than changing the references in the drawing? In effect you would be regressing all the design files (drawings, models etc.) back in time to a previous design state, in the knowledge that you could bring revert them to their present state whenever you wanted.
I'm looking at SVN options for SolidWorks here, with revision control being one of the main reasons for adopting it. One big concern I have is whether SolidWorks uses absolute or relative file paths for references, as a user can checkout working copies to any folder they want. I think there's a logic table in the SW help on this, will have to dig it out.
Retrieving data ...