Re: SVN compatibility question

[Eric Johnson]

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 
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 

SVN compatibility question

[Eric Ahlstrom]

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 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: Error---After upgrading from subversion 1.6 to 1.8.

[Daniel Shahaf]

Reyaz wrote on Mon, Mar 28, 2016 at 02:44:49 -0700:
> Hi Team, 
> 
> We have recently upgraded subversion from 1.6 version to 1.8 version on RHEL
> 5.8. After upgrade we are getting below error in error_log file. Before
> upgrade everything working fine.Now we are unable to access the projects
> with below given error. 
> 
> 
> "[Tue Mar 15 03:06:57 2016] [error] [client 10.191.212.115] Failed to load
> the mod_authz_svn config: Section name 'Ents_0590_EA:2113:ELA Amd #5 - 340
> BCDs:/' contains non-canonical fspath '2113:ELA Amd #5 - 340 BCDs:/''" 

Your /u10//svnauthfile contains:

[Ents_0590_EA:2113:ELA Amd #5 - 340 BCDs:/]

That's parsed as:

repository name = "Ents_0590_EA"
path within the repository = "2113:ELA Amd #5 - 340 BCDs:/"

Which is invalid.  (The path in section headers must have a leading
slash and no trailing slash.)

This is an instance of
https://subversion.apache.org/docs/release-notes/1.8#authz-fspath-syntax;
paraphrasing that:

 Subversion 1.7 and earlier would silently ignore those sections of
 the authz file; directives in those sections would never apply.
 That's been fixed in this release: Subversion will now error out
 if the authz file contains such a section.

It is not possible to escape colons in that context.  You may be able to
rename the repository (or create a symlink to it and start using that).

And see https://subversion.apache.org/docs/release-notes/1.7#http-redirects

Cheers,

Daniel

RE: Error---After upgrading from subversion 1.6 to 1.8.

[Bert Huijben]

> -Original Message-
> From: Reyaz [mailto:skreyazaha...@gmail.com]
> Sent: maandag 28 maart 2016 11:45
> To: users@subversion.apache.org
> Subject: Error---After upgrading from subversion 1.6 to 1.8.
> 
> Hi Team,
> 
> We have recently upgraded subversion from 1.6 version to 1.8 version on
> RHEL
> 5.8. After upgrade we are getting below error in error_log file. Before
> upgrade everything working fine.Now we are unable to access the projects
> with below given error.
> 
> 
> "[Tue Mar 15 03:06:57 2016] [error] [client 10.191.212.115] Failed to load
> the mod_authz_svn config: Section name 'Ents_0590_EA:2113:ELA Amd #5 -
> 340
> BCDs:/' contains non-canonical fspath '2113:ELA Amd #5 - 340 BCDs:/''"

It looks like there is some invalid path in the authz file.

This should be the file that you configured in
[[
AuthzSVNAccessFile /u10//svnauthfile
]]
in your configuration.


Bert