RE: SVN compatibility question

[JT . Miller]

I’m not an expert on Solidworks, but our MEs use Solidworks here at work and I 
know that Solidworks includes its own version control system. The MEs here do 
not use Subversion because of this. A quick Google check shows Solidworks 
Workgroup PDM is the Solidworks way to do what you want (I’m sure there will be 
a software upgrade cost, but it sounds like it will pay for itself many times 
over…). I would highly suggest contacting a Solidworks rep and have them walk 
you through the Solidworks way of doing things (so that you can at least make 
an informed decision).

From the Solidworks Workgroup PDM propaganda:

Easy to set up and use, SolidWorks® Workgroup PDM
automatically captures file revision histories automatically and
allows you and other members of your prod- uct design team
to instantly access desired files, determine who has worked
on them, and see exactly when changes were made. By
accelerating time-to-market, SolidWorks Workgroup PDM
helps your design team minimize errors and duplicated efforts..

SolidWorks Workgroup PDM provides an effective approach
to securing files through vaulting – a simple, yet highly reliable
and safe system for storing shared project files. Vaulting allows
members of your design team to share files systematically,
checking them in and out of the Vault one at a time to avoid the
possibility of a team member accidentally overwriting a file or
spending time working on the wrong file revision.

Good Luck,
JT Miller

From: Eric Ahlstrom [mailto:eric.ahlst...@borsight.com]
Sent: Tuesday, March 29, 2016 12:53 PM
To: users@subversion.apache.org
Subject: SVN compatibility question

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  Fax: (801) 409-1487
eric.ahlst...@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.

Re: svn: E175002: Unexpected HTTP status 418 ' Not Found'

[Stefan Hett]

Hi Jordi,


Dear svn users

We are trying to perform a commit of an added file to a folder already 
in the repository server. A changed file works fine, however when we 
try to commit an added file the following error is reported:


svn: E175002: Commit failed (details follow):

svn: E175002: Unexpected HTTP status 418 ' Not Found' on 
'/svn/reposthe_path_of_the_file '


Has anyone found something similar?

Well, I take it you discovered a teapot (hint: check HTTP status code 
418). ;-)
I'd assume some server side issue here. Without knowing more details 
about your environment it's hard to tell.



--
Regards,
Stefan Hett

Re: SVN compatibility question

[Nico Kadel-Garcia]

On Tue, Mar 29, 2016 at 1:53 PM, Eric Ahlstrom
 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.ahlst...@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.

Re: SVN Checkout failed

[Stefan Hett]

Hi Inder,


HI,

Got error while checking out:

CheckOut:

 [echo] Checking Out Project from SVN = TRAX_FCS

  [svn]  started ...

  [svn] This application has halted due to an unexpected error.

  [svn] A crash report and minidump file were saved to disk, you 
can find them here:


  [svn] C:\Windows\svn-crash-log20160302143040.log

  [svn] C:\Windows\svn-crash-log20160302143040.dmp

  [svn] Please send the log file to users@subversion.apache.org to 
help us analyze


  [svn] and solve this problem.

  [svn] NOTE: The crash report and minidump files can contain some 
sensitive information


  [svn] (filenames, partial file content, usernames and passwords 
etc.)


  [svn]  failed !

Attached is the DMP and the LOG files.

Turtoise SVN Version Info:



TortoiseSVN 1.8.11, Build 26392 - 64 Bit , 2015/03/19 18:50:20

Subversion 1.8.13, -release

apr 1.5.1

apr-util 1.5.4

serf 1.3.8

OpenSSL 1.0.2a 19 Mar 2015

zlib 1.2.8



*Regards,*

*Inder*

While you provide the TSVN details here, your log states you were using 
SilkSVN 1.8.9. Since that version is quite old, I suggest you upgrade to 
the latest 1.8 version (SilkSVN 1.8.15) and test whether that resolved 
the crash you have.



--
Regards,
Stefan Hett