This probably should have been posted to uses_at_subversion.tigris.org (and
you might want to repost there).
1.
I think SVN versions directories as well as files. If you update a file
and commit, the new revision is in SVN. If you add an empty directory
and commit, the new directory is in SVN. If you update 3 of 100 files
and commit, the directory doesn't change in SVN, but the revisions on
all 3 files do.
Essentially, whenever you make any changes to your entire set of working
folders, you can commit those changes atomically and Subversion will
reflect those changes as a particular revision. You don't need (or
necessarily want) a directory-per-document for this to work well.
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.
Worst case: If you lose repo data, you're likely to have local copies
somewhere. But you really should be backing up and verifying your
data--with any solution you choose.
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.
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.
4.
Your content within Subversion is not typically version-aware. Whenever
you commit, operate on the files mostly as though they're not in a
version control system, and then commit the changes when you're done.
Once somebody updates to your revision's changes, they will see the
files as you committed them. You only need to do funky hyperlinking
stuff if you add a new copy of a file or something.
5.
Not applicable, no implications of the "SVN directory structure". Note
that with SVN you can make branches/tags which appear in other
directories (but you would typically be working only in the trunk or in
a particular branch so your local copy would not show the full set of
SVN directories).
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.
-----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
Received on 2008-03-07 17:28:39 CET