I've read all the replies I can find on this topic, and although I'm well
aware of the responses that state how much it goes against the philosophical
teachings of version control, I want to go ahead and do it because it seems
to make the most sense for my scenario.
I've setup a repository on a network share, and a working copy on another
network share - we are not using a subversion server yet, but we will once
we get our little test scenario up and running properly. Client systems are
MS Windows XP and we are on a domain. In testing, all goes well; however,
if I mod a file and save it (without committing), then someone else tries to
commit that file (or mod it, then commit) we get the error:
"
Commit failed (details follow):
Can't create directory 'T:/Repository Folder/db/transactions/5-1.txn': The
system cannot find the file specified.
"
If the test is done the other way around, then it works - I can commit a
file someone else has modded. I am assuming this is because I was the one
who created the repository and the working copy, so maybe it's a permissions
thing? We also tried removing the file from the repository and re-adding it
from the other machine/account, but the same error occurred. This scenario
is necessary so that files don't accidentally get permanently locked into
the changed status, like when people go on holidays or get hit by a bus etc.
The reason I want to use this much frowned-upon shared working copy model is
that we are looking to use TSVN to manage versions of project documentation.
The docs are shared by several teams, and some members will not be very
savvy when it comes to something like TSVN - we need to make the process as
transparent as possible, and as close to our traditional (non-managed)
system as we can get it. TSVN is perfect because we only need to teach
members of the different teams to add new files to the repository and to
commit changes after modding. If we get this working properly and someone
forgets to commit a file, someone should be able to do it on their behalf
once the circumstances are properly established.
I can't see any way that people will accept making local working copies of
3gigs of documents, and splitting up the documentation will just complicate
matters. Documentation is hierarchically organised into several projects,
and each project has several administrative folders and a work unit folder.
Each work unit folder can contain hundreds of sub-folders, each containing 5
or 6 documents. It seems that adding a new work unit folder would not be
easy for someone who is not very technically minded - I would think some
folders would get lost in space. I don't think flattening out our document
model would help much with administration, and currently we use shell
extensions that allow us to sort folders by various aspects of the naming
convention for easy cross-referencing. If we were working with individual
work unit folders we would not be able to cross-reference without checking
all work unit folders out. To put it simply, I want to maintain the
existing hierarchical structure without complicating the add/checkout/commit
procedure.
I am very interested firstly in how to prevent the error message I'm
getting, and secondly in hearing from anyone who has been managing
moderately large document repositories with TSVN or another subversion based
client. We have explored various options, but the shared working copy with
TSVN appears to be the most seamless and painless way to transition our
document library to source control. Anything has got to be better than what
we have at the moment - going to old backup tapes to retrieve old document
copies would be a pain.
Thankyou for TSVN, it is a valuable project for many.
Troy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon May 2 03:30:10 2005