You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Carter <pu...@soycarretero.com> on 2008/05/15 16:14:42 UTC
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: RE: Working Copy On Shared Drive - Binary Files Only - Seeking a definitive answer
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Thu, 15 May 2008 17:44:30 +0100, "Richard Yale"
<Ri...@uk.linedata.com> wrote:
>With a binary file I think you will loose the opportunity to merge
>changes,
TortoiseSVN does a good job of handling MS Word files.
>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.
Not true. Only diffs are stored for binaries -
http://subversion.tigris.org/faq.html#binary-files
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
SVN for Document control (Was: Working Copy On Shared Drive - Binary
Files Only - Seeking a definitive answer)
Posted by Steve Carter <pu...@soycarretero.com>.
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@soycarretero.com]
> Sent: 15 May 2008 17:15
> To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Working Copy On Shared Drive - Binary Files Only - Seeking a definitive answer
Posted by Richard Yale <Ri...@uk.linedata.com>.
Hi Steve
I'm quite new to Subversion and this may also be a little off subject,
but a thought occurred to me that may give you better exploitation of
Subversions strengths, so I'll throw in my 2 pennies worth.
With a binary file I think you will loose 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.
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, I just mean it
looks almost the same next time you open it). You loose some document
features but you gain portability in addition to the better Subversion
management features and concurrent edditing.
Regards,
Rich
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
-----Original Message-----
From: Steve Carter [mailto:public07@soycarretero.com]
Sent: 15 May 2008 17:15
To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy On Shared Drive - Binary Files Only - Seeking a definitive
answer
Posted by km...@rockwellcollins.com.
Steve Carter <pu...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org