On Fri, Mar 7, 2008 at 11:27 AM, Gleason, Todd <tgleason_at_impac.com> wrote:
> This probably should have been posted to uses_at_subversion.tigris.org (and
> you might want to repost there).
> 2.
>
> I believe this is BDB/FSFS specific. I think BDB stores the current
> version and diffs back to the old versions, whereas I think FSFS is the
> reverse. I don't know if SVN internally does anything to improve
> performance here or not, but I'd like to know (I haven't seen much on
> this topic). But always keep good backups! And running proper
> verification tools on a regular basis is a good idea too.
Subversion uses a skip-delta algorithm (regardless of back-end).
Generally, yes, each revision is stored as a diff against the
previous. However, based on certain criteria, it will occasionally
decide to store a full copy. The performance hit isn't as bad as if
*every* revision were based upon the previous, all the way back to the
beginning of time.
> 3.
>
> I don't know a thing about server configuration, but we use Apache and
> user names are properly reflected in our commits. We're using LDAP
> authentication, but I don't know more than that.
Yeah, I'm not sure what rj is referring to here.
> A general question to Subversion folks, for people who might use SVN for
> document management: Can you configure the server to ask for password
> on every commit? This might be useful for people who need stricter
> electronic signature options.
Yes, you can (and in most cases should) configure SVN to require a
password for any operation, especially commits. User credentials are
cached in your local OS user account's home directory, so once you've
authenticated once, you shouldn't be prompted again. This can be
problematic if multiple people share a workstation login account, but
that's another ball of security wax that's outside the realm of SVN.
> 6.
>
> You can use post-commit hooks in SVN to run anything you like, including
> generation of reports, sending emails, integrating into third-party
> tools, etc.
Anything that can be generated from items stored in your repository
shouldn't be versioned. For example, a report definition file (layout,
queries, etc.) should be versioned, but *generally* one wouldn't
version the actual reports that are generated.
> -----Original Message-----
> From: rj [mailto:rtjoseph1_at_gmail.com]
> Sent: Friday, March 07, 2008 8:04 AM
> To: users_at_tortoisesvn.tigris.org
> Cc: ray_at_aarden.us
> Subject: Evaluating SVN as a Document Management Solution
>
> I am looking at SVN as a document management tool in our
> orginization. We are an engineering company performing work for a
> variety of petrochemical companies. We typically have 20 to 30
> projects going at any one time. We generate support documents,
> deliverable documents, and database content. Support documents are
> typically in MS Office applications, deliverables are typically
> drawings in AutoCAD or Microstation, and database content is typically
> financial data from which reports are generated.
>
> From this, I have a couple concerns:
>
> 1) From what I have read, SVN versions entire directories and not
> just files. We may have 20 to 100 revisions to each drawing (each
> project having about 1000 drawings). Because there are no hard links
> between drawings (not even rigid links) there is little advantage for
> versioning an entire directory unless each drawing is in its own
> directory. What is a good way to look at this so I can most
> effectively use the features of SVN for drawings?
>
> 2) It looks like SVN stores changes to files and not just the new,
> complete content. This suggests that when I open a file out from a
> repository that SVN must go back through all revisions and rebuild the
> file. There would seem to be two difficulties here:
> a) It will take time to rebuild a 10 MB drawing through 100
> revisions
> b) If any of the files are corrupted, I loose every thing for that
> file.
> Is this the case and is there any way to mitigate this?
>
> 3) The FAQ says that when using Apache authentification, SVN never
> sees who is doing the transaction and thus can not log who owns the
> new content. This is a significant security issue. The stated work
> around is for the worker to state their identification in the SVN
> call. This has more concerns:
> a) This is overhead a user will elect not to do and thus we will
> loose ownership of content
> b) It allows for a masquarade - changes being made in the name of
> some one else
> Is there an automated workaround for this?
>
> 4) Do hyperlinks work between documents in the same directories and/
> or different directories as versions escalate? How does the author
> design hyperlinks so they work across versioned directories?
>
> 5) As we develop work process and associated work flow diagrams,
> these documents will have hyper links. We will want users to be able
> to access the lates version without having to know anything about
> SVN. How would we design and work process & flow development SVN
> directory structure and a deployment method so we could both provide
> for ease of use by the general employee and continue to manage changes
> (and keep hyperlink management simple)?
>
> 6) We have a variety of database applications which we use both
> interactively and generate periodic and adhoc reports. Some of these
> databases are corporate wide and others are project specific. What
> would be some choices of managing the data and reports?
>
> I am looking forward to all comments.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-03-07 17:42:46 CET