Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: 
 <CANyH0e9sa4Y_0yDpgt-wwNDbzjEgvs68kHGa1gk8p+N_5e9W2A@mail.gmail.com>
References: 
 <CANyH0e9sa4Y_0yDpgt-wwNDbzjEgvs68kHGa1gk8p+N_5e9W2A@mail.gmail.com>
From: Eric Johnson <eric@tibco.com>
Date: Tue, 29 Mar 2016 22:43:08 -0700
Message-ID: 
 <CANu9=NczMxF3O9P+RDHfy3uspimxTqYota4BHb3edSj-=U5JHg@mail.gmail.com>
Subject: Re: SVN compatibility question
To: Eric Ahlstrom <eric.ahlstrom@borsight.com>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Content-Type: multipart/alternative; boundary=001a113f389e029d8a052f3da083

--001a113f389e029d8a052f3da083
Content-Type: text/plain; charset=UTF-8

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

--001a113f389e029d8a052f3da083
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That&#39;s an interesting problem you describe. I&#39;m no=
t familiar with SolidWorks, but you provide enough information to take some=
 guesses.<div><br></div><div>Subversion uses an &quot;optimistic lock&quot;=
 design approach which might trigger some of the problems you&#39;re seeing=
. You say you wish to &quot;prevent&quot; users from editing the same file =
at the same time, but Subversion usually doesn&#39;t prevent people from wo=
rking 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 SolidWor=
ks users don&#39;t even necessarily know which files on disk will change fo=
r 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-wr=
iting other people&#39;s changes, and changes to files that appear independ=
ent, but turn out to be contradictory. (This happens with source code all t=
he time, but is much easier to resolve, it sounds like).</div><div><br></di=
v><div>To sidestep the optimistic lock problem, perhaps adopt a convention =
where you have a &quot;semaphore&quot; file. Use Subversion&#39;s pessimist=
ic lock capability (<a href=3D"http://svnbook.red-bean.com/en/1.7/svn.advan=
ced.locking.html">http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.h=
tml</a>). People shouldn&#39;t work on a project unless they can get a pess=
imistic lock on the project. This will require training your users....</div=
><div><br></div><div>In addition to that, it sounds like SolidWorks is comp=
letely oblivious to Subversion - so if it goes and renames or changes files=
, it doesn&#39;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.</div><div><br></div><div>A quick browse of the inter=
net suggests that using Subversion (TortoiseSVN) is likely going to be pain=
ful, unless you figure out the corner cases, and train your users to recogn=
ize them and fix them before they are a problem (<a href=3D"https://forum.s=
olidworks.com/thread/48193">https://forum.solidworks.com/thread/48193</a>).=
</div><div><br></div><div>You&#39;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 serv=
er are you running? That might be the place to start.</div><div><br></div><=
div>Note that with the newer Subversion clients (starting 1.7, I think), Su=
bversion only puts one &quot;.svn&quot; folder at the root of the working c=
opy, instead of a &quot;.svn&quot; folder in each directory of the working =
copy. I&#39;m guessing that SolidWorks expects a folder with few or no extr=
aneous 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&#39;t ever see/tou=
ch the .svn folder. From your description, I&#39;m guessing this is part of=
 the problem you&#39;ve run into after upgrading clients to a newer version=
 of Subversion.</div><div><br></div><div>There&#39;s a different way of thi=
nking about this problem that might work better for you, but it depends on =
your users.</div><div><br></div><div>One option is to use Subversion to &qu=
ot;snapshot&quot; the work that people are doing, and commit those snapshot=
s. For this you might find treating your &quot;project&quot; as a &quot;ven=
dor&quot; folder instead. See=C2=A0<a href=3D"http://svnbook.red-bean.com/e=
n/1.7/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general">http://svnb=
ook.red-bean.com/en/1.7/svn.advanced.vendorbr.html#svn.advanced.vendorbr.ge=
neral</a> .</div><div><br></div><div>Using the vendoring approach, have peo=
ple check out a working copy, but not do their work in that copy - instead =
do their work from a folder that is an <i>export</i>=C2=A0of the Subversion=
 working copy (no extraneous .svn folders). Then when their work in SW is d=
one, use svn_load_dirs to change the Subversion working copy to look just l=
ike the SW project folder. Then commit that. Then have the next person chec=
k out the latest version of the working copy, export into a clean folder, a=
nd make their changes. Truly a pain, though, so probably a last resort. Thi=
s approach might be useful for learning how SW changes files, so you can tr=
ain people on what is happening, though.</div><div><br></div><div>My sugges=
tions, summarized:</div><div><ul><li>Upgrade your server (what version are =
you at now?) - this shouldn&#39;t affect clients, except possibly to make e=
verything work better.</li><li>Upgrade your clients, but <i>make sure</i>=
=C2=A0your users check out working copies at the parent folder of the SW pr=
oject, not the SW folder itself. This may require reorganizing the director=
y structure of the repository so that you can check out the parent folder w=
ithout grabbing too much extra stuff.</li><li>Identify and train your users=
 on the various scenarios that they will encounter.</li></ul></div><div>Hop=
efully that gives you some clues.</div><div><br></div><div>Good luck!</div>=
<div><br></div><div>Eric.</div></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Tue, Mar 29, 2016 at 10:53 AM, Eric Ahlstrom <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:eric.ahlstrom@borsight.com" target=3D"_bla=
nk">eric.ahlstrom@borsight.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-f=
amily:times new roman,serif">To whom it may concern,</div><div class=3D"gma=
il_default" style=3D"font-family:times new roman,serif"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:times new roman,serif">Sorry, I=
9;m not a software developer so this message is not following the protocol =
for reporting bugs.=C2=A0 Our company primarily deals with aircraft electro=
nics integration.=C2=A0 Software is a small part of our operations and our =
people have used Tortoise SVN successfully for years in that area.</div><di=
v class=3D"gmail_default" style=3D"font-family:times new roman,serif"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:times new roman,seri=
f">Our hardware department uses a popular CAD package called SolidWorks.=C2=
=A0 Normally, this package allows us to build and document assemblies with =
parts automatically populating BOM&#39;s and reporting to multiple assembli=
es.=C2=A0 In a standard file system, we can rename files, move them from on=
e directory to another, restructure common part files, etc. all while Solid=
Works maintains the links between these files and their associations.</div>=
<div class=3D"gmail_default" style=3D"font-family:times new roman,serif"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:times new roman,s=
erif">In an effort to maintain version control and prevent multiple users f=
rom editing the same file at the same time, we migrated all of our CAD file=
s to Tortoise SVN.=C2=A0 Now our assemblies routinely crash, hardware loses=
 its associations randomly, BOM&#39;s collapse and have to be rebuilt, and =
renaming/reorganizing files requires incredibly complex work arounds.=C2=A0=
 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.=C2=A0 Often, 100 hour assemblies are cor=
rupted and have to be remade from scratch.</div><div class=3D"gmail_default=
" style=3D"font-family:times new roman,serif"><br></div><div class=3D"gmail=
_default" style=3D"font-family:times new roman,serif">We are running 1.6.16=
.21511 and any attempts to upgrade to a newer version have crashed everythi=
ng.=C2=A0 Obviously, this version is out of date and at some point will no =
longer be available for new users.=C2=A0 Please do not say we simply need t=
o upgrade.=C2=A0 We need some input from a party that understands how Solid=
Works manipulates files.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:times new roman,serif"><br></div><div class=3D"gmail_default" style=3D=
"font-family:times new roman,serif">It seems that SolidWorks is fundamental=
ly incompatible with SVN.=C2=A0 If possible, could the SVN community tell u=
s if this is the case?=C2=A0 Does anyone know of another organization using=
 SVN for SolidWorks PDM (product data management)?</div><div class=3D"gmail=
_default" style=3D"font-family:times new roman,serif"><br></div><div class=
=3D"gmail_default" style=3D"font-family:times new roman,serif">Thank you,</=
div><div><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><div =
dir=3D"ltr"><font face=3D"times new roman, serif"><font size=3D"2">Eric Ahl=
strom</font><br><font size=3D"1">R&amp;D Manager<br></font></font><div><fon=
t face=3D"times new roman, serif" size=3D"1">Borsight Inc.=C2=A03525 Airpor=
t Road, =C2=A0Ogden, UT 84405</font></div><font face=3D"times new roman, se=
rif" size=3D"1">Mobile:=C2=A0<a value=3D"+14356409236" style=3D"color:rgb(1=
7,85,204)">(</a><u><a href=3D"tel:775%29%20302-6762" value=3D"+17753026762"=
 target=3D"_blank">775) 302-6762</a></u>=C2=A0 Fax:=C2=A0<a value=3D"+18014=
091487" style=3D"color:rgb(17,85,204)">(801) 409-1487</a></font></div><div =
dir=3D"ltr"><font face=3D"times new roman, serif"><font size=3D"1">eric.ahl=
strom@Borsight.com=C2=A0<a href=3D"http://www.borsight.com/" style=3D"color=
:rgb(17,85,204)" target=3D"_blank">http://www.Borsight.com</a>=C2=A0</font>=
<br><font size=3D"1">This e-mail is proprietary, privileged or otherwise pr=
otected by law. The=C2=A0</font><font size=3D"1">information is solely inte=
nded for the named addressee (or a person=C2=A0</font><font size=3D"1">resp=
onsible for delivering it to the addressee). If you are not the intended=C2=
=A0</font><font size=3D"1">recipient of this message, you are not authorize=
d to read, print, retain,=C2=A0</font><font size=3D"1">copy or disseminate =
this message or any part of it. If you have received=C2=A0</font><font size=
=3D"1">this e-mail in error, please notify the sender immediately by return=
 e-mail=C2=A0</font><font size=3D"1">and delete it from your computer.</fon=
t></font><br></div></div></div></div></div></div></div>
</div>
</blockquote></div><br></div>

--001a113f389e029d8a052f3da083--