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?
I don't think you'll have much of a problem. You may want to section
off your project tree into sub-directories rather then have 1000
drawings in a single folder.
We use SVN in a similar fashion for our work. I can't discuss
specifics, but we do projects for a large variety of clients. Our
project team is spread across the US with a central repository at our
main office. (Actually, we have multiple repositories.)
For us, we don't care much about permissions. You either have commit
permissions to the entire job repository, or you don't. Other companies
may choose to break up a monolithic repository by client or by project.
We prefer to deal with fewer, larger repositories because we never
entirely know which project we'll be working with on a daily basis.
So we have a central repository called "our-jobs", accessed via svn+ssh
at the URL:
svn+ssh://svn.example.com/our-jobs
We then setup a public key in PuTTY/Pageant, set it to load
automatically when the user logs in (using Pageant), and things work
just fine from there. (We found it easier to setup svn+ssh, along with
being more secure. And the ability to use Pageant to prevent our users
from being constantly prompted for passwords.)
Our job tree looks like:
our-jobs/letter/companyname/projectgroup/projectid/projectfolders
letter = A-Z
- We split our list that way because we might have a few dozen companies
under each letter of the alphabet. It would also allow us down the road
to split each letter grouping into a separate repository if we needed to
for performance reasons.
companyname = Company code and name, i.e. "EXC-ExampleCo"
projectgroup = We break our projects apart on 100 project number
boundaries. So if a company has projects EXC0001 to EXC0500, we split
that into sub-folders of EXC00xx, EXC01xx, EXC02xx, EXC03xx, EXC04xx.
Otherwise we might have 500 project folders under a single company. A
better way to do this may be to sort your projects by start year "2006",
"2007", "2008" -- which will work better once sparse directory support
is added in SVN 1.5
projectid = is typically something like EXC0352-RedBall
projectfolders = could be organized however you want. We usually have
sub-folders like "Doc", "Media", "Web", "Mailings", "Reports",
"SourceData", etc. Possibly with sub-folder divisions under there. Our
sub-folders are fairly standard across projects, so folks know where to
look.
Basically, you can setup your repository to match how your company
decides to work. You'll have to make the call whether you want a lot of
small repositories, or a few large repositories. We prefer to mash
everything for a particular project together into a single URL. Other
companies that are more silo-like, may choose to have a separate
repository for things like Artwork, and the person responsible for
integration merely uses a svn:externals to link in from the artwork
repository.
> 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...
A possible example of this is the issue where you have one Access MDB
file that links to another Access MDB file. Because MS Access is
slightly braindead, it stores the link as an absolute address. So if
your destination MDB (that you linked to) was at:
C:\Jobs\X\XYZCo\XYZ00xx\XYZ0030\Data\MyData.mdb
Then the link will break if another developer checks that MDB out to a
different location on their local drive.
Our solution for this issue is that we mandate that the root URL of our
jobs repository (svn+ssh://svn.example.com/our-jobs) always gets checked
out to C:\Jobs. By bringing everything down (which is a waste of local
disk space, but that's inexpensive) in the same locations, we avoid the
issue of having files not being linked properly.
If your tool is smarter and stores the linked locations as relative
addresses (i.e. look for "MyData.mdb" in the current folder) then you'll
have less issues with linking.
> 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)?
You'll have to train them at least a little bit to know to do SVN
Updates before they start working.
One trick that we do is to run a "svn up" on the root of our local
working copy of the jobs folder at 3am overnight. That brings down all
of the latest changes to the user's workstation / laptop so that they
are mostly up to date when they come in the next morning.
For documentation that won't be distributed outside the company... you
may be better served by setting up a wiki (which typically have
versioning, etc) or a CMS system on a central web server. Of course,
that doesn't let you disconnect entirely and still see documentation.
SVN may not be the best tool for all cases.
> 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?
We do most of our reporting inside of MSAccess. Either linking back to
a central database, or by exporting a snapshot of the data to a local
MDB file and working from there. MDB files store very nicely inside of
SVN. The only trick is to make sure that if you link back to a central
database that all of your workstations share the same ODBC naming
convention for the data source.
...
Basically SVN works for us because:
- We are geographically distributed.
- We want the latest versions of files on our laptops.
- We don't care if we have excess information downloaded, it just means
we can get up to speed on a question about another project faster. We
still plan on taking advantage of sparse directory support when it comes
out in SVN 1.5.
- We can work without being connected, except for not being able to
commit changes back to the central repository.
- Our SSH keys for doing commits are locked down so that they are only
usable with SVN. SVN itself is fairly secure so that the worst that
could happen if someone stole our SVN SSH key would be that they could
impersonate us and attempt to delete things out of the repository.
Since SVN doesn't have an obliterate command, any damage done would be
easily rectified.
- It's rare that more then one of us is working on a particular project
at the same time as someone else. When we do, we make sure to update
and commit frequently to avoid small conflicts turning into big conflicts.
- We used VSS+SourceOffSite for about 6 years before switching over to
SVN+TortoiseSVN back in 2006.
- If our laptops crash, we can get back to work fairly quickly. And we
only lose data that had yet to be checked in.
- We love versioning. Being able to go back to a previous revision in a
flash, or doing a diff of a web page file to see what someone changed.
We're willing to put up with the downsides and drawbacks to gain versioning.
---------------------------------------------------------------------
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-11 22:50:05 CET