[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Having working folder located on network drive

From: David Dyer-Bennet <illegalname_at_gmail.com>
Date: Tue, 22 Mar 2011 12:38:07 -0700 (PDT)

On Monday, March 21, 2011 10:36:35 AM UTC-5, Andy wrote:
> On Mon, Mar 21, 2011 at 11:34, Craig <shady..._at_gmail.com> wrote:
> > From that thread: "Placing personal working copies on a network share
> > is not
> > really discouraged, but it is not exactly supported either due to the
> > known problems with such devices."
> >
> > Can anyone elaborate on these known issues?
> Permissions issues, speed, and user A overwriting user B's changes
> (it's shared space, after all) to name 3.

In my case, it isn't shared space; it's my private network disk. I can
access it from any desktop in the company, but other people can't. And it's
backed up regularly. This is terribly useful when I have to debug on
special hardware, for example, that I don't have on my desktop PC.

Also, the network shares are backed up automatically each night, whereas the
local disks aren't. While the earlier suggestion of manually committing to
a personal branch would get the data into the repository (where it is
presumably backed up), that still requires a manual action; the whole point
of automatic backups is to not depend on your users always remembering to do
the right thing :-) .

My own workaround has been to run a daily process that uses rsync to update
copies on my network disk of my working directories on my local disk. Since
I keep them all under one subdir, I don't even have to remember to update
the list, it just does everything under that subdirectory. However, that
doesn't give me access to anything more recent than overnight from other
systems, so it's not really ideal.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-03-22 20:39:24 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.