That's an interesting problem you describe. I'm not familiar with
SolidWorks, but you provide enough information to take some guesses.
Subversion uses an "optimistic lock" design approach which might trigger
some of the problems you're seeing. You say you wish to "prevent" users
from editing the same file at the same time, but Subversion usually doesn't
prevent people from working on the same files at the same time. Compounding
that, it sounds like the SolidWorks project changes many files at the same
time. This means that not only can you not prevent users from making those
changes, the SolidWorks users don't even necessarily know which files on
disk will change for any particular change they make in the program. So if
you use Subversion to share changes to files, you may get an odd
combination of people over-writing other people's changes, and changes to
files that appear independent, but turn out to be contradictory. (This
happens with source code all the time, but is much easier to resolve, it
sounds like).
To sidestep the optimistic lock problem, perhaps adopt a convention where
you have a "semaphore" file. Use Subversion's pessimistic lock capability (
http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html). People
shouldn't work on a project unless they can get a pessimistic lock on the
project. This will require training your users....
In addition to that, it sounds like SolidWorks is completely oblivious to
Subversion - so if it goes and renames or changes files, it doesn't perform
the Subversion actions. Particularly if SW does a lot of renaming, this
will cause problems, because then the users will have to go and do fix-up
operations with the Subversion working copy - deleting files here and there.
A quick browse of the internet suggests that using Subversion (TortoiseSVN)
is likely going to be painful, unless you figure out the corner cases, and
train your users to recognize them and fix them before they are a problem (
https://forum.solidworks.com/thread/48193).
You've indicated that upgrading is a problem. Are you talking about
upgrading the server, or the clients? You should be able to upgrade the
server without too much worry. What version of the server are you running?
That might be the place to start.
Note that with the newer Subversion clients (starting 1.7, I think),
Subversion only puts one ".svn" folder at the root of the working copy,
instead of a ".svn" folder in each directory of the working copy. I'm
guessing that SolidWorks expects a folder with few or no extraneous files
in it - perhaps it is even modifying the contents of the .svn folder. To
avoid that problem, make sure you check out a working copy that is a
*parent* of the SW project folder, so that SW doesn't ever see/touch the
.svn folder. From your description, I'm guessing this is part of the
problem you've run into after upgrading clients to a newer version of
Subversion.
There's a different way of thinking about this problem that might work
better for you, but it depends on your users.
One option is to use Subversion to "snapshot" the work that people are
doing, and commit those snapshots. For this you might find treating your
"project" as a "vendor" folder instead. See
http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
.
Using the vendoring approach, have people check out a working copy, but not
do their work in that copy - instead do their work from a folder that is an
*export* of the Subversion working copy (no extraneous .svn folders). Then
when their work in SW is done, use svn_load_dirs to change the Subversion
working copy to look just like the SW project folder. Then commit that.
Then have the next person check out the latest version of the working copy,
export into a clean folder, and make their changes. Truly a pain, though,
so probably a last resort. This approach might be useful for learning how
SW changes files, so you can train people on what is happening, though.
My suggestions, summarized:
- Upgrade your server (what version are you at now?) - this shouldn't
affect clients, except possibly to make everything work better.
- Upgrade your clients, but *make sure* your users check out working
copies at the parent folder of the SW project, not the SW folder itself.
This may require reorganizing the directory structure of the repository so
that you can check out the parent folder without grabbing too much extra
stuff.
- Identify and train your users on the various scenarios that they will
encounter.
Hopefully that gives you some clues.
Good luck!
Eric.
On Tue, Mar 29, 2016 at 10:53 AM, 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
> 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.
>
> 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.
>
> 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)?
>
> Thank you,
> Eric Ahlstrom
> R&D Manager
> Borsight Inc. 3525 Airport Road, Ogden, UT 84405
> Mobile: (*775) 302-6762 <775%29%20302-6762>* Fax: (801) 409-1487
> eric.ahlstrom@Borsight.com http://www.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 07:43:48 CEST