[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Migration thoughts, VSS/SOS to SVN

From: Thomas Harold <tgh_at_tgharold.com>
Date: 2006-10-20 19:05:49 CEST

Frank Gruman wrote:
> Perhaps the question back to you is this - is any part of the
> existing local folder structure above your example already a working
> copy? If so, then I could see where your issue comes from. But then
> I have to ask why all of that needed to be checked out to begin with.

Yes, everything from C:\Ours\Jobs on down maps to a project in the

> Does each user have to keep a copy of every project they are working
> with in this same structure on their local pc? Or could they simply
> create a folder of c:\ours\jobs\ACWI01030_PipeDreams and then check
> out the repository folder of the same name into that?

The former. The working copy structure has to match everyone else to
minimize issues with brain-dead software that assume absolute paths when
linking between different files. Software that we're not going to (or
can't) replace so we have to work within its limitations.

(This is something that VSS and SOS handled very gracefully. You could
set the working copy at the root node, browse the repository structure
and get a file N levels deep without worrying about the intermediate
structure. There's very little overlap between our jobs and our jobs
only live a few days before they are closed and we start a new one.
Most of us are juggling multiple jobs with the need to be able to
quickly look at another user's job files. We used SOS+VSS as a
versioning storage system in order to work remotely from the main office
and to keep everyone in sync.)

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 20 19:06:47 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.