RE: CVS to SVN conversion

"Wadhavankar, Hemant" <[email protected]>
Newsgroups gmane.comp.version-control.subversion.cvs2svn.user
Message-ID <[email protected]>
Hey Michael,
Thanks a ton for very detailed description.

Regarding bad solution - I got one more "bad" solution.

I edited ,v file in CVS repo and deleted line having mention of branch from it and cvs2svn could proceed with conversion and got completed as well. I am not sure if this safe option to do so - do you by any chance?

By the way - thanks a ton for replying all queries sent thus far!

Best,
Hemant
Unstoppable......


-----Original Message-----
From: Michael Haggerty [mailto:[email protected]] 
Sent: Thursday, March 04, 2010 3:36 PM
To: Wadhavankar, Hemant
Cc: [email protected]
Subject: Re: CVS to SVN conversion

Wadhavankar, Hemant wrote:
> When I tried to convert partial CVS database, I get following errors
> and conversion stops due to this. Is there any way to resolve this errors?
> 
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkLayer.map,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkLayer.v,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkLayerCDC.map,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkRxStage.v,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkSasSm.v,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkSataSm.v,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/LinkTxStage.v,v' has default branch=1.1.1 but also a revision 1.2
> ERROR: File '/tmp/svn/repo/cobra/rtl/CosedaModules/ITLinkLayer/Include/PrimDefsLink.vh,v' has default branch=1.1.1 but also a revision 1.2

A "default branch" is set when code is imported into cvs using "cvs
import".  This feature is meant to support tracking upstream vendor code
while making local changes, but it is often misused to import the user's
own code.

If a CVS checkout is done with no tag specified, and there is an active
default branch in a file, then the last revision in that branch is
checked out instead of the 1.x (trunk) branch.

Normally, the default branch is active until the user commits his own
modification to a file, in which case the user's commit usually becomes
revision 1.2 and the default branch is cleared.  From then on, a CVS
checkout of trunk gives the latest 1.x revision.

cvs2svn can handle this normal case OK.  It assumes that the transition
from "have default branch" to "don't have default branch" occurs when
revision 1.2 was committed.

But in your unusual case, there was a revision 1.2 but there was still a
default branch set.  AFAIK this situation can only arise if users use
the "cvs admin" command to set a default branch again after having
committed revision 1.2.  In this case there is no way for cvs2svn to
figure out during what period of time the default branch was *not*
active, so it cannot figure out what file version to include in the
trunk in the Subversion repository.

There is no good solution to this problem because CVS doesn't record
enough information to reconstruct the true history.  Here are some bad
solutions:

1. Remove the 1.2, 1.3, 1.4, etc. revisions for these files using "cvs
admin -o".  This has the effect of discarding historical data.

2. Remove the default branch for these files (I think this can be done
using "cvs admin -b").  This has the effect of changing the revision
that is checked out on trunk.

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2454910

To unsubscribe from this discussion, e-mail: [[email protected]].
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.