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

Re: Multi-user working copy: ownership changes

From: Andy Levy <andy.levy_at_gmail.com>
Date: Tue, 20 Nov 2012 18:48:16 -0500

On Tue, Nov 20, 2012 at 6:42 PM, Wayne Johnson <wayne_at_zk.com> wrote:

> >
> > Now my question: Can you think of any solution which would satisfy the
> > following requirements?
> >
> > - A single working copy being used for data exchange with our customer.
> >
> > - Multiple Windows users that are able to run TortoiseSVN on that
> > working copy (on a Windows share) without it getting "damaged" by SVN
> > as described above. It can be assumed that those users do not access
> > the working copy simultaneously because there will always be only one
> > person in charge of doing so.
>
> Well I don't think you can avoid the corruption if multiple users are
> working on the on the same working copy at the same time. I think you need
> to look at this from a different angle.
>
> Someone has already suggested having your customer access the repository
> directly through webdav.
>
> If the only purpose is to share the information with the customer then you
> could have a task that monitors the repository and exports the current
> release version to the customer share automatically. It would take a
> little bit of scripting work but I think it has other advantages besides
> avoiding the working copy corruption.
>
>
That wouldn't even require "monitoring" the repository - just write a
post-commit hook script that exports what's needed to the correct location.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029793

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-11-21 00:49:02 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.