Why not define the module to checkout to the specified directory? In the modules file:
module -d <your directory> repos eg. html -d mydirectory/html <pathfromreposroot>/htmlsource Then to checkout html: $ cd /home/myworkspace $ cvs co html And you'll have your directory structure, /home/myworkspace/mydirectory/html. Matt > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 9:19 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: DIfferent workspace directories than repository... > > > > > > Um, why do you need this specific layout in the > > repository? It seems to me that the structure of > > the repository should be determined by the structure > > of what must be checked out. > > Some would disagree with you on that... myself included. I > was hoping that I could get CVS to treat a directory as a > true project/first-class object. Not just as a directory. > > Many people create Projects and Subprojects within their SCM > tools that are not simply treated as 'Directories'. But as > first-class objects. In this way, they can have attributes. > One of those attributes is workspace location. Its very > common. In several popular SCM tools, I could create a > subproject ("html") under the "MyProject" project and assign > it a workspace location of "/home/myworkspace/mydirectory/html". > > Check out the Tigris project (www.tigris.org) which is > addressing these kinds of issues that CVS apparently doesn't meet. > > > > > CVS will use the identity map when checking out, > > but afterwards each directory has its own metadata > > (in the CVS subdirectory) so that it knows where it > > came from. This means that it will retain the > > mapping while you move the directories around on > > your own. Therefore, if you do something like > > "cvs co bin; mkdir mydirectory; mv bin mydirectory/" > > you will still be able to do updates and checkins > > from mydirectory/bin. > > Well, that answers my question. It can be done, but with > manual kludges involved. I was hoping to avoid such things. > > Thanks for the response and insight. I appreciate it! > > -- Rick Grashel > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
