[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OT: TortoiseCVS - Use Network or Y:\Drive for Sandbox

From: Bulgrien, Kevin
Subject: OT: TortoiseCVS - Use Network or Y:\Drive for Sandbox
Date: Fri, 27 Jan 2006 12:28:36 -0600

-----Original Message-----
Subject: Re: TortoiseCVS - Use Network or Y:\Drive for Sandbox

Thanks, Kevin.  One more question. Do you know why it says 'NOT
Recommended' beside the Check Box to 'Allow Network Drives' ?  We
currently use PVCS Version Manager and it uses y:\pvcs as the default
Check Out location.
-----Original Message-----

Don't "know" details, and the farthest I will go in guessing will be that
it has something to do with issues like NFS / async / write buffering /
network link breakage / etc.  Some people who use network shares have no
idea if their system/network admin has a clue - to overstate the issue.

I've seen Tortoise go bonkers once or twice in a few years of it being
used up here.  Now that you ask, it strikes me that it is possible it
was not necessarily a bug, but could have been network related.  If
Tortoise botched its files in the sandbox CVS directories because a
server or the network burped, it would mess up usage, and would elevate
risk of loss since CVS comes behind you and edits files after commit
operations.  Thing is recovery was not an unacceptable ordeal.  Usually
a recheck-out or something like that fixed it.  Maybe some minor losses
that due to the frequency of the backup schedule, but not major.

When it comes down to it, I don't care if the client works on a network
share.  ;-)  I always check that box right after installing.  Well,
really it is more that the risk is mitigated by choice of network
infrastructure and backup plans.  In our system, if you don't work
on a network share, your work does not get backed up by IT and that far
overshadows any risk of using the network resource.

Honestly, it is probably stock boilerplate so you do not go ballistic at
the TortoiseCVS developers if your infrastructure fails because that is a
place where lots of people have had problems because they did not
understand or ignored the risks involved in using the tools they used.  I
go by the principle that if over time I have a low recurance of fault and
I know I have a reliable backup scheme, the risk is acceptable even if
people rant and rave about it.

What it boils down to is that design engineering and development is ALL
about risk management.  You'll never remove all risk and there will always
be some gambling going on.  You just have to do your best to stack the odds
in your favor.  Sometimes you'll get burned, but hopefully less than you
get fortunate.  Unlike the old adage, blind ignorance is definitely not
bliss, but with sufficient CYA, it might be ok if one doesn't know exactly
why "NOT recommented" is there.

P.S. & Fine Print Disclaimer.  In my case, 99.9% of network share usage is
done on a server I also happen to administer.  Now, if IT were managing the
server... hmm... I might not be able to answer quite the same way.  ;-)

Kevin R. Bulgrien
Design and Development Engineer

General Dynamics C4 Systems

reply via email to

[Prev in Thread] Current Thread [Next in Thread]