rj wrote:
> 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?
SVN versions both files and folders. In fact, if you change one file,
the revision number increases. And revision numbers are global for the
whole repository, no matter how many files/folders are in it.
> 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?
SVN stores changes, yes. But as from version 1.4.x on, the repository
stores the latest version in full, and recreates older versions from the
diffs. So you won't see any speed problems when you use the latest
version. You migh (I say 'might' here because I doubt you would ever
notice it) if you want to get a very old version back. But: I would bet
good money here that you wouldn't notice 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
I think you're mixing some things here. If you're using SSH tunneling
(for using with svnserve), *then* svnserve never knows who the user is -
the whole authentication is handled by SSH.
If however you're using Apache, then Subversion *will* know which user
accesses the repository.
If you could point me to that FAQ, I might be able to change it to make
that more clear.
> 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?
That depends: if you're using absolute hyperlinks to files, they won't
work if others don't have the working copy in the exact same location.
For example, if you create a hyperlink to file:///c:/project/myfile
then others must have their working copy also on C:\project or the link
won't work.
But if you're talking about http:// hyperlinks, you won't have any problems.
> 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)?
If you keep your repository served by Apache, then your users can use
any webbrowser to see the latest version.
An example is our own source code repository:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk
(use 'guest' as username, leave password empty).
> 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?
Just think about a folder structure you would use if you had to use a
simple fileserver. Then recreate the same folder structure in your
repository.
Another way would be to create separate repositories for your
corporate-wide stuff and for each of your projects.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-03-07 18:59:57 CET