Richard Yale wrote:
> With a binary file I think you will lose the opportunity to merge
> changes, so only one person editing at a time or things go south quite
> quickly, and the changes might bloat the repository a bit as the full
> binary needs to be stored for each change.
>
Thanks for these thoughts, though we already considered these issues.
As Greg points out on his reply, the problems are minor (Svn uses a
binary diff for transmitting and applying changes, so the bloat problem
goes away). Also Tortoise behaves very well in the case of diffing Word
or Excel documents, starting the relevant application in a mode where it
shows the differences.
> What if you went over to saving files in html? Word does a reasonable
> job at saving to this format (don't shoot me please,
(* goes to buy a shotgun *) :) We already did something like this on
our last development project. We actually kept and edited Word
documents but put a VBA "Document_OnClose" event in them that exported a
copy as HTML when you saved the word doc. The idea was that the HTML
version allowed diffing and also scripting of our requirements tracing.
In practice the requirements tracing worked OK but the diffs were
useless for human readers, since the smallest change to the word doc
resulted in sweeping differences in the exported HTML.
For the development side, we are moving towards LaTeX (or docbook) to
give us concurrent editing and automated content generation (e.g. API
reference). The setup cost is high, but that happens at the relaxed end
of the project, whereas our experiences with Word show that Word's
difficulties come when trying to merge subdocuments into the main one
(styles keep changing and tables will not stay how you put them) which
happens at the urgent end of the project (i.e. just before a milestone).
However, this is all on the development side (where design documents and
test specs are updated frequently, concurrently and on the fly, and the
authors all appreciate the notions of conflicts and atomic changes). We
still have the requirement that non-developers shall be able to write
word documents and the original question about a working copy on a
shared drive still stands.
> -----Original Message-----
>
>
> From: Steve Carter [mailto:public07_at_soycarretero.com]
> Sent: 15 May 2008 17:15
> To: users_at_subversion.tigris.org
> Subject: Working Copy On Shared Drive - Binary Files Only - Seeking a
> definitive answer
>
> 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.
>
> 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?
>
> Thanks in advance,
>
> Steve Carter
>
>
---------------------------------------------------------------------
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-16 10:51:12 CEST