On Tue, Mar 29, 2016 at 1:53 PM, Eric Ahlstrom
<eric.ahlstrom_at_borsight.com> wrote:
> To whom it may concern,
>
> Sorry, I'm not a software developer so this message is not following the
> protocol for reporting bugs. Our company primarily deals with aircraft
> electronics integration. Software is a small part of our operations and our
> people have used Tortoise SVN successfully for years in that area.
>
> Our hardware department uses a popular CAD package called SolidWorks.
> Normally, this package allows us to build and document assemblies with parts
> automatically populating BOM's and reporting to multiple assemblies. In a
> standard file system, we can rename files, move them from one directory to
> another, restructure common part files, etc. all while SolidWorks maintains
> the links between these files and their associations.
>
> In an effort to maintain version control and prevent multiple users from
> editing the same file at the same time, we migrated all of our CAD files to
> Tortoise SVN. Now our assemblies routinely crash, hardware loses its
Big missing piece here. Is everyone working in their own local working
copy of an upstream Subversion repository? Doing their work locally,
and expecting it all to merge gracefully back into an upstream master
Subversion repository? Because doing that with what are basically
text-based binary files such as Gerber files, and expecting the merges
to occur gracefully, is going to *suck*. It's possible in the
pre-commit hooks and Subversion configs to say "these classes of files
cannot be merged, they must be overwritten".
> associations randomly, BOM's collapse and have to be rebuilt, and
> renaming/reorganizing files requires incredibly complex work arounds.
> Essentially, a CAD user has to know every file association in advance of a
> move, open every association, and copy/rename/edit/delete dozens of files in
> specific combination and order. Often, 100 hour assemblies are corrupted
> and have to be remade from scratch.
Ouch. Sounds like you need to do something more like branching, and do
your work in branches, not all work in the same structure
simultaneously.
> We are running 1.6.16.21511 and any attempts to upgrade to a newer version
> have crashed everything. Obviously, this version is out of date and at some
> point will no longer be available for new users. Please do not say we
> simply need to upgrade. We need some input from a party that understands
> how SolidWorks manipulates files.
If your TortoiseSVN is way out of date and can't be upgraded.
> It seems that SolidWorks is fundamentally incompatible with SVN. If
> possible, could the SVN community tell us if this is the case? Does anyone
> know of another organization using SVN for SolidWorks PDM (product data
> management)?
Or maybe you could call SolidWorks? I bet they've run into similar
issues with attempts to source control working files.
> Thank you,
> Eric Ahlstrom
> R&D Manager
> Borsight Inc. 3525 Airport Road, Ogden, UT 84405
> Mobile: (775) 302-6762 Fax: (801) 409-1487
> eric.ahlstrom@Borsight.com http://www.Borsight.com
> This e-mail is proprietary, privileged or otherwise protected by law. The
> information is solely intended for the named addressee (or a person
> responsible for delivering it to the addressee). If you are not the intended
> recipient of this message, you are not authorized to read, print, retain,
> copy or disseminate this message or any part of it. If you have received
> this e-mail in error, please notify the sender immediately by return e-mail
> and delete it from your computer.
Received on 2016-03-30 15:35:40 CEST