This is the first time I've ever seen someone use CVS revision numbers in
this particular way. Each file gets a unique CVS revision. If fmtcrt is a
directory, you're basically checking out all files with the revision 2.1
inside this directory tree. These files may not have anything to do with
each other.
However, seeing the numbering starting with a 2.x instead of a 1.x , it
looks like you used the old "cvs commit -r2.0" command to force this, and
did this to try to keep all the revisions lined up. This is the first time
I've ever seen a site that actually does this, and I've been a configuration
manager for over two decades.
Almost everyone who uses CVS never did this. You look at any CVS manual or
discussion, and you'll see people decrying the practice. You're suppose to
use tags and branches to keep things straight since it is almost impossible
to keep CVS revision numbers in sync with each other.
I would recommend you revisit your old methodologies and follow more
standard practice. Still, what was done was done. Now, you need to unwind
that:
First of all, you need to checkout your entire repository and remove the
cvs2svn:cvs-rev property. Everytime you do a new commit, the new revision of
the file gets this property from the previous revision, and that's wrong.
Wait until you try a merge and see this property appear over and over as a
merge issue. Fun times for all.
Don't worry, you're not the only one who fell for this trap. I too thought
this property sounded wonderful until I realized the mess it generated. The
only cure is to do a checkout of the entire repository and remove that
stupid cvs2svn:cvs-rev number, so that it doesn't hurt your newer revisions
of your files.
After you've deleted all those cvs2svn:cvs-rev properties, we need to
convert your CVS revision numbers to Subversion tags. Fortunately tagging in
Subversion is almost instantanious and takes up almost no room in the
repository.
You have the cvs2svn:cvs-rev property on the revisions of the files, but
unfortunately Subversion gives you no easy way to query that. You'll have to
search for each and every file in your repository, and then do a "svn log"
on that file to find the revisions that file was commited in. Then, you need
to do a "svn propget -r$revnum cvs2svn:cvs-rev on that particular revision
to see what Subversion revision it was committed to. This will take a
loooong time.
Fortunately, because of the way you forced these revision numbers to remain
in sync, and because of the way the cvs2svn conversion works, once you find
that your CVS revision 2.1 is Subversion revision 12345 for one file, it
will likely be revision 12345 for all files in your Subversion repository.
What you will do is make a Subversion tag to mark this revision, and you'll
name this tag after the CVS revision. I highly recommend that you create a
subdirectory inside you Subversion tags directory for these revisions. That
way, you don't clutter your tags directory with them. In fact, I have three
subdirectories under my tags CVS (for the old CVS build tags), REL (for
release tags), and DEV (for the daily build tags). Let's say that CVS
revision 2.1 is Subversion revision 12345, you'll do something like this:
$ svn cp -r12345 -m"Creating CVS 2.1 'revision' tag in Subversion"
svn://svn/trunk/myrpoj svn://svn/tags/CVS/2.1/myproj
Now, when you need to see your old CVS 2.1 revision, you can do this:
$ svn co svn://svn/tags/CVS/2.1/myproj myproj-cvs-2.1
If you like working with revision tags, you'll be happy to know that
Subversion does a much better job because it revisions the entire
repository. Most sites don't bother with build numbering, and instead rely
on the revision tag for the files used in a build. The tagging only happens
once that revision is actually released in production. Of course, your
revision tags aren't 3.1 or something simple. They'll be something like
13384, but developers seem to get use to this.
If you want "cleaner" revision numbers, create tags and branches.
Fortunately, creating a tag or branch in Subversion is extremely quick and
easy to do. And, unlike CVS, you can use almost any character you want in
your tag or branch names.
On Fri, Jun 12, 2009 at 2:54 AM, Amit Verma <amit.verma_at_rsystems.com> wrote:
> Hi
>
> We have migrated a huge CVS repository to SVN using CVS2SVN tool two weeks
> back.
>
> Earlier while our development team was with CVS, we were relying heavily on
> CVS revision numbers for our development process. The snapshot of our
> earlier CVS usages is as -
>
> cvs co -r "2.1" fmtcrt
>
> But now because we are with SVN, we need to map those earlier CVS revision
> numbers and module-names (for example "fmtcrt", see above) with migrated SVN
> revision numbers and SVN module path, so that our existing development could
> stay flawless. Here is the snapshot of our tried efforts -
>
> svn co -r "350" file:///home/svn/svnRepository/trunk/fmtcrt
>
> Here we can see that CVS revision number "2.1" has been mapped to SVN
> revision number "350" and the CVS module "fmtcrt" has been mapped to SVN
> path "trunk/fmtcrt", within the SVN present repository
> "home/svn/svnRepository/".
>
> Now, because our CVS repository had huge volume of modules (multiply this
> with several CVS revision number for each and every CVS module), it is
> becoming very hard for us to map these revision number and module-name from
> CVS to SVN for our entire team for last two weeks.
>
> Is there a way we can map CVS revision number to migrated SVN revision
> number? Please help and thank you very much in advance.
>
>
> Note - We used SVN dump to map the CVS revision numbers and module-names to
> SVN revision numbers and new module-paths altogether. Following is the
> command we used, to generate the SVN dump file -
>
> svnadmin dump svnRep > svnDumpFile
>
>
> Thanks
> Amit Verma
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2361515
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2361722
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-12 22:14:28 CEST