FC1 SVN-1.0.5
One of the things that we did with CVS was use the version tag that is
issued with a check in. This did an auto versioning for us that we
liked and have gotten use to (MOC stuff here). I understand that SVN
does repos level versioning which I'm not sure how to do a best practice
with. So here is my scenerio:
I have a CVS repos with many many developement projects in them, all
under a meaningful directory structure. So the repos would be like:
<path2repos>/sh
<path2repos>/pl
<path2repos>/py
<path2repos>/tcl
<path2repos>/c
<path2repos>/cpp
<path2repos>/sql
and then under each of those dirs would be directories for each of our
projects, such as:
<path2repos>/sql/storm
<path2repos>/sql/mmail
...
<path2repos>/c/gsalt
<path2repos>/c/fwa
This worked well for me and my team because it grouped like projects
together for more RAD level dev. Tags were used only for final
releases.
I'm trying to setup the SVN repos so that it works well with the way we
have gotten use to working yet addresses more of what SVN has to offer.
So my question is what is the best way to set up a repos that treats
each project (or module as it were in CVS) as its own entity and have
easy access to a group of projects such as listed above.
I've used the basic migration script:
cvs2svn.py -s <path2svnrepos>/sql <path2cvsrepos>/sql/
and this creates the <path2repos>/sql with trunk, branches, and tags
subdirs. And then under each of these is the specific project subdirs.
However, this removes any use of the SVN revision number like the CVS
revision number could be used.
I've thought about making each project a SVN repository in and of itself
which seems to be the best way to do it... But I thought I would ask
you all to see if maybe I'm missing something. Any suggestions would be
appreciated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 8 07:56:00 2004