On Tue, Nov 20, 2012 at 5:02 AM, Yves Forkl <yvesforkl02_at_arcor.de> wrote:
> Hi,
>
> yes, this post is (somehow) about the subject of multi-user working
> copies. I am aware that sharing a working copy is, in general, a very bad
> basis for collaboration, when multiple users contribute to the same working
> copy (risking severe conflicts and refusing to make use of proper VC at
> all).
>
> However, in our scenario, we don't use this working copy for multi-lateral
> internal development, but solely for the exchange of data (created by us)
> with our customer and further partners. Hence, at least from my point of
> view, our entire company is to be considered as the "user" who owns this
> single working copy on our side.
>
>
I have to wonder if Subversion is the right tool for your needs in the
first place. Seems like Dropbox or Skydrive might be more appropriate.
If you're staying with Subvesion, why use a WC at all? Can you map the
repository as a drive via WebDAV?
> Given that SVN strongly (and rightfully) discourages multi-user working
> copies, its internal locking mechanism is implemented in a way which leads
> to problems when different Windows users apply TortoiseSVN operations to
> the same working copy directory:
>
> Certain internal SVN files (e.g. "dir-prop-base" and "entries") will
> change ownership to the current user and will be write-protected. As a
> consequence, if the Windows user who is the owner of the corking copy
> accesses the working copy the next time, he/she is not allowed to remove
> that write protection as a prerequisite to start (most) SVN operations.
>
> In this case, the Sys Admin needs to reset ownership of the mentioned
> files to the original owner - which is unacceptable for production usage.
>
> 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.
>
> One idea might be to prevent SVN from changing ownership of the mentioned
> files, but I fear that might be very hard to achieve.
>
>
But now you're fighting with Windows internals & security, not Subversion
itself. And if it's TSVN doing these changes (which, if you're not already
an admin, you must become in order to change ownership), what happens if
someone uses a different Subversion client? It's really the Subversion
libraries doing the WC handling here, and Windows is applying ownership &
security at an even lower level than that.
You're also ignoring the fact that sharing the WC means that user A can
commit user B's changes, either maliciously or unwittingly. What if a
change isn't ready to be committed yet.
> Another idea might be to do rather the opposite, i.e. have the whole
> working copy change ownership to the current user as soon as someone calls
> any TortoiseSVN functions (so that "dir-prop-base" and "entries" will have
> the correct ownership). I wonder if this is feasible, though.
>
>
See above.
>
> Of course, there also might be other approaches trying to avoid the above
> problem altogether. In particularly, we have come up with this one (which
> would require quite some changes in our setup, though):
>
> Access the single working copy only as one single user, through a
> "generic" account which is mainly used to synchronize the working copy with
> another local directory.
>
>
But now you'll have a loss of accountability. Changes cannot be attributed
to the actual author.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029731
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-11-20 17:00:43 CET