cvs2git - branches without sprout and related git orphan commits
James Doyle <[email protected]> Fri, 14 Jul 2017 16:31:20 -0400
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.user |
|---|---|
| Message-ID | <[email protected]> |
Hi, Our cvs2git conversion is resulting in a git repo with multiple orphan commits (commits without any parents at all and are not the initial commit). I can't find any issue tracker issues or mailing list threads with exactly this same problem. We're using cvs2git from cvs2svn 2.4.0 (22 September 2012). The resulting repo has an initial commit from 2001, but also ends up with 2 orphan commits from 2006 and 2014: [builder@stlbldd-new smsmis]$ git log --remotes=origin/branch-* --reverse --date=local --pretty=format:"%h parents(%p) %ad %an %s" | grep "parents()" c837450 parents() Mon Jul 23 18:50:02 2001 jdoyle Added starter project file and package hierarchy for diagram files. 56154d6 parents() Fri Jan 27 17:54:32 2006 jdoyle SIR #: (none) Description: Added new build config files for new asmp2-check test area used for ASM Phase 2 Checkout. 8a97b86 parents() Thu Oct 16 12:50:50 2014 jdoyle SIR #: (none) Description: New Data Mapping document for Divisional Accounting Release 3. In progress. Completed These orphan commits cause the history to look very odd for all the files that existed during that time period, e.g. when doing "git log --graph". When I look at git-dump.dat, I can locate those commit entries and see that they are the first commit for the respective branch, but do not have a "from :NNNNN" line, e.g.: commit refs/heads/branch-div-account-3-dev mark :1000062509 committer jdoyle <> 1413478250 +0000 data 246 SIR #: (none) Description: New Data Mapping document for Divisional Accounting Release 3. In progress. Completed basic algorithm for DaOnlyBidsBean. Need to add algorithm steps for populating default subaccounts and for any validation desired. M 100644 :71793 sms/docs/population/Bids Data Mapping.docx There are later manufactured commit entries for the branch but their message only says "Cherrypick" and not "Sprout", and they don't have a "from :NNNNN" line either: commit refs/heads/branch-div-account-3-dev mark :1000062536 committer cvs2svn <[email protected]> 1413894819 +0000 data 750981 This commit was manufactured by cvs2svn to create branch 'branch-div- account-3-dev'. Cherrypick from master 2014-10-21 12:33:38 UTC npatel 'SIR #: (none)': ... Cherrypick from master 2014-10-10 14:38:23 UTC builder 'Baseline output export generated with SMS/MIS trunk build 2014-10-10 11:48:25 GMT': ... data-exports/baseline-output/sms/SERVICE_SETTLEMENT_T.sql M 100644 :79404 sms/resources/config/producttest/testapps/pnodevirtualbidproxyconfig-application.xml ... All the other branches seem to start with a manufactured commit entry with a "from :NNNN" line and a commit message that says "Sprout from", e.g.: commit refs/heads/branch-37_0_X mark :1000073083 committer cvs2svn <[email protected]> 1488218199 +0000 data 19007 This commit was manufactured by cvs2svn to create branch 'branch-37_0_X'. Sprout from master 2017-02-27 17:56:36 UTC npatel 'SIR #: (none)' Delete: CVSROOT/checkoutlist CVSROOT/commitinfo ... data-exports/baseline-output/sms/VAR_STANDARD_STLMNT_T.sql from :1000073080 M 100644 :88564 sms/src/htdocs/metering/MeteringUI/app/view/fcmdemandassets/MainModel.js ... M 100644 :147297 sms/test/database/model/CONTRACT_T.sql M 100644 :57575 mis/src/database/views/MIS_DAILYPOS_SCHED_2_VAR_V.sql D data-exports/baseline-output/sms/ENERGY_RT_STLMNT_T.sql D data-exports/baseline-output/sms/NCPC_RT_ARD_CRDT_SP_DTL_T.sql ... D data-exports/baseline-output/sms/RSV_CUST_LZ_T.sql D CVSROOT/checkoutlist It kind of seems like for these 2 branches, cvs2git is waiting to create a manufactured commit for the branch until too late, after a regular user commit has already been created. I think this is probably related to our cherrypicking the branch contents in CVS, and I could alter the CVS repository files if it would help, but I can't pinpoint what it is about these 2 branches that doesn't work, when there are 100s of other branches that seem to have been OK. What is the best way to troubleshoot what's going on? Thanks, Jim ------------------------------------------------------ http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=3263939 To unsubscribe from this discussion, e-mail: [[email protected]].