Steve Carter <public07_at_soycarretero.com> wrote on 05/15/2008 11:14:42 AM:
> Hi,
>
> My employer has chosen to use SVN for Document Managment purposes. This
> means SVN and Tortoise being used to version lots of binary files
> (mostly Microsoft Office files and PDFs).
>
> The old way we did this was to simply keep the files on a shared drive
> in between major project milestones and use a clunky, proprietary
> Document Management System for checkpoints at milestones.
>
> With the switch-over we gain a revision history (woo hoo! now document
> guys can be almost as civilized as developers!) and we can use a
> repository URL and Revision to refer to a released document-set. So far
> so good.
>
> But what we lose is MS Office's feature whereby it tells you "This
> document is currently opened by X for editing." Instead we use SVN file
> locking, but since SVN allows you to steal locks, and the users are
> document guys not developers, I don't have much faith in that system.
> Stealable Locks + Ignorance ~= No Locks.
You can use pre-lock and pre-unlock scripts to restrict who can steal
locks. (The only thing this can't stop is the user manually resetting
the R/O bit on the file...)
> So we are considering the scenario where a working copy is placed on the
> shared drive. Googling, and reading these archives, I see lots of
> "oooh, bad idea" posts, but nothing actually substantive. The only
> failure scenario I saw mentioned was where two people edit the same file
> with an editor that doesn't anticipate concurrent users. Since Office
> DOES anticipate this, this is not a problem.
>
> It sounds like a bad idea to me, but there are at least two advocates
> for doing this, so I would need a strong, rational argument for why not
> to do it. Does anyone have a good technical reason why this won't
> work? e.g. is user or host information stored in the working copy?
Never tried it, but most working copy corruption we see is when
the working copy has been stored on a network resource (not even
adding in the multi-user aspect)
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-15 18:24:20 CEST