{"thread":{"id":"10206","subject":"Problem with git-cvsimport","startedAt":"2007-10-09T09:25:51Z","lastAt":"2007-10-31T12:40:29Z","messageCount":11,"participants":["Thomas Pasch","Jan Wielemaker","Gerald (Jerry) Carter","Eyvind Bernhardsen","Michael Haggerty","Mike Snitzer","Robin Rosenberg","Aidan Van Dyk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55242","messageId":"470B491F.9020306@jentro.com","threadId":"10206","inReplyTo":null,"subject":"Problem with git-cvsimport","fromName":"Thomas Pasch","fromEmail":"thomas.pasch@jentro.com","sentAt":"2007-10-09T09:25:51Z","receivedAt":"2007-10-09T09:25:51Z","isPatch":false,"sender":{"key":"thomas.pasch@jentro.com","avatar":null},"body":"Hello,\n\nusing git-cvsimport (1.5.3.4), it dies with\n\nUpdate\nguidance-common/src/java/com/jentro/manager/guidance/common/servlet/IconServlet.java:\n2104 bytes\nTree ID 01cb84cbee2e70a712459be6601b993603eed5bd\nParent ID dcd8dc76f4638d1994165070c9813202992d546a\nCommitted patch 3775 (bmw +0000 2004-10-14 11:10:43)\nCommit ID 53c68066f71651b057884e1101cda3967070724d\nFetching\nguidance-common/src/java/com/jentro/manager/guidance/common/serverapi/GuidanceException.java\n  v 1.14.4.2\nUpdate\nguidance-common/src/java/com/jentro/manager/guidance/common/serverapi/GuidanceException.java:\n3718 bytes\nTree ID 886268190ac2cb28b5f1e6cdb309054bcb8fa38e\nParent ID 53c68066f71651b057884e1101cda3967070724d\nMerge parent branch: master\nfatal: Not a valid object name master\nUse of uninitialized value in chomp at /usr/bin/git-cvsimport line 766.\nUse of uninitialized value in pattern match (m//) at\n/usr/bin/git-cvsimport line 527.\nUse of uninitialized value in concatenation (.) or string at\n/usr/bin/git-cvsimport line 767.\nCannot get commit id ():\n\nWhat can I do to avoid this problem?\n\nCheers,\n\nThomas\n"},{"id":"55269","messageId":"200710091447.50501.wielemak@science.uva.nl","threadId":"10206","inReplyTo":"470B491F.9020306@jentro.com","subject":"Re: Problem with git-cvsimport","fromName":"Jan Wielemaker","fromEmail":"wielemak@science.uva.nl","sentAt":"2007-10-09T12:47:49Z","receivedAt":"2007-10-09T12:47:49Z","isPatch":false,"sender":{"key":"wielemak@science.uva.nl","avatar":null},"body":"On Tuesday 09 October 2007 11:25, Thomas Pasch wrote:\n> Hello,\n>\n> using git-cvsimport (1.5.3.4), it dies with\n>\n> Update\n> guidance-common/src/java/com/jentro/manager/guidance/common/servlet/IconSer\n>vlet.java: 2104 bytes\n> Tree ID 01cb84cbee2e70a712459be6601b993603eed5bd\n> Parent ID dcd8dc76f4638d1994165070c9813202992d546a\n> Committed patch 3775 (bmw +0000 2004-10-14 11:10:43)\n> Commit ID 53c68066f71651b057884e1101cda3967070724d\n> Fetching\n> guidance-common/src/java/com/jentro/manager/guidance/common/serverapi/Guida\n>nceException.java v 1.14.4.2\n> Update\n> guidance-common/src/java/com/jentro/manager/guidance/common/serverapi/Guida\n>nceException.java: 3718 bytes\n> Tree ID 886268190ac2cb28b5f1e6cdb309054bcb8fa38e\n> Parent ID 53c68066f71651b057884e1101cda3967070724d\n> Merge parent branch: master\n> fatal: Not a valid object name master\n> Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 766.\n> Use of uninitialized value in pattern match (m//) at\n> /usr/bin/git-cvsimport line 527.\n> Use of uninitialized value in concatenation (.) or string at\n> /usr/bin/git-cvsimport line 767.\n> Cannot get commit id ():\n>\n> What can I do to avoid this problem?\n\nI've had some similar problem.  I've converted two big old repositories by\nfirst converting to SVN using:\n\n\tcvs2svn -s myrepo-svn /path/to/cvsmodule\n\tgit-svnimport -i -u -C /path/to-git file://myrepo-svn\n\nWorked like a charm\n\n\tCheers --- Jan\n"},{"id":"55280","messageId":"470B8049.1090308@samba.org","threadId":"10206","inReplyTo":"200710091447.50501.wielemak@science.uva.nl","subject":"Re: Problem with git-cvsimport","fromName":"Gerald (Jerry) Carter","fromEmail":"jerry@samba.org","sentAt":"2007-10-09T13:21:13Z","receivedAt":"2007-10-09T13:21:13Z","isPatch":false,"sender":{"key":"jerry@samba.org","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJan Wielemaker wrote:\n\n> I've had some similar problem.  I've converted two big old \n> repositories by first converting to SVN using:\n> \n> \tcvs2svn -s myrepo-svn /path/to/cvsmodule\n> \tgit-svnimport -i -u -C /path/to-git file://myrepo-svn\n\nI would actually plug using cvs2svn to convert directly to git.\nSee this thread for Michael's original announcement.\n\n   http://marc.info/?l=git&m=118592701426175&w=2\n\nI'm in the process of drafting Samba's own git repos from\nthe CVS and SVN history (http://gitweb.samba.org/).\n\n\n\n\ncheers, jerry\n=====================================================================\nSamba                                    ------- http://www.samba.org\nCenteris                         -----------  http://www.centeris.com\n\"What man is a man who does not make the world better?\"      --Balian\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHC4BJIR7qMdg1EfYRAlQ4AKDctlXFv0kcT51sA6P99qjVrPJ+MgCfWkCB\nwPSf6l06UIlz0HERasHbryg=\n=zSSf\n-----END PGP SIGNATURE-----\n"},{"id":"55303","messageId":"47065A5D-D170-4D11-A802-85376F97F8D2@orakel.ntnu.no","threadId":"10206","inReplyTo":"470B8049.1090308@samba.org","subject":"Re: Problem with git-cvsimport","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git-list@orakel.ntnu.no","sentAt":"2007-10-09T19:41:01Z","receivedAt":"2007-10-09T19:41:01Z","isPatch":false,"sender":{"key":"eyvind-git-list@orakel.ntnu.no","avatar":null},"body":"On 9. okt.. 2007, at 15.21, Gerald (Jerry) Carter wrote:\n\n> I would actually plug using cvs2svn to convert directly to git.\n> See this thread for Michael's original announcement.\n>\n>   http://marc.info/?l=git&m=118592701426175&w=2\n\nSeconded!  I've tried git-cvsimport, parsecvs, fromcvs, and cvs2svn on  \nmy employer's many large CVS modules, and cvs2svn is the only one that  \nhas never mangled an import.\n\nThat said, it is a work in progress, so there are some caveats:\n\n* Setting up the direct conversion to git is more work than it should  \n(and probably will, eventually) be.\n\n* There is no support for incremental importing, and git-cvsimport  \n_will_ mess up your git repository sooner or later if you try to use  \nit for subsequent incremental imports.\n\n* Tags each get a branch with a single commit, with the actual tag  \npointing to that commit.  This makes it harder than necessary to  \nfigure out what the history looks like; gitk's default view won't show  \nany tags, for example, since it only shows the master branch and not  \nthe single-commit tag branches.\n\n* Branches all get a useless commit at their branch point.  All  \nbranches from the main branch appear to be merged from the vendor  \nbranch (ie, the useless commit has the vendor branch as an extra  \nparent), which might make sense to someone who knows what the vendor  \nbranch is for, but makes no sense to me.  This combined with the  \nprevious point makes \"gitk --all\" look needlessly spaghetti-like if  \nyou have a slightly complicated CVS history.\n\nTo sum up, cvs2svn gets the important stuff right, but has some sharp  \ncorners you need to watch so you don't put an eye out.\n\nEyvind Bernhardsen\n"},{"id":"55327","messageId":"470C3A3A.2070809@alum.mit.edu","threadId":"10206","inReplyTo":"47065A5D-D170-4D11-A802-85376F97F8D2@orakel.ntnu.no","subject":"Re: Problem with git-cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2007-10-10T02:34:34Z","receivedAt":"2007-10-10T02:34:34Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Eyvind Bernhardsen wrote:\n> On 9. okt.. 2007, at 15.21, Gerald (Jerry) Carter wrote:\n>> I would actually plug using cvs2svn to convert directly to git.\n>> See this thread for Michael's original announcement.\n>>\n>>   http://marc.info/?l=git&m=118592701426175&w=2\n> \n> Seconded!  I've tried git-cvsimport, parsecvs, fromcvs, and cvs2svn on\n> my employer's many large CVS modules, and cvs2svn is the only one that\n> has never mangled an import.\n\nI'm glad this worked.\n\n> That said, it is a work in progress, so there are some caveats:\n> \n> [...]\n> \n> * Tags each get a branch with a single commit, with the actual tag\n> pointing to that commit.  This makes it harder than necessary to figure\n> out what the history looks like; gitk's default view won't show any\n> tags, for example, since it only shows the master branch and not the\n> single-commit tag branches.\n\nI just fixed this in cvs2svn trunk r4213.  Now it reuses a single branch\ncalled 'refs/heads/TAG.FIXUP' whenever it needs to make a tag fixup\nbranch, and it resets that branch when done.  (Resetting the tag fixup\nbranch changes it to 0000000000000000000000000000000000000000 but\ndoesn't really delete it; I don't know the ramifications of that but at\nleast it doesn't appear in gitk output any more.)\n\n> * Branches all get a useless commit at their branch point.  All branches\n> from the main branch appear to be merged from the vendor branch (ie, the\n> useless commit has the vendor branch as an extra parent), which might\n> make sense to someone who knows what the vendor branch is for, but makes\n> no sense to me.  This combined with the previous point makes \"gitk\n> --all\" look needlessly spaghetti-like if you have a slightly complicated\n> CVS history.\n\nI assume that the \"useless commit\" that you are referring to is the one\nwith log message \"This commit was manufactured by cvs2svn to create\nbranch 'BRANCH'.\"  Is that correct?\n\nI'm not a git expert, so I don't know whether these commits are in fact\nuseless.  But let me explain the reason I put them in and you can tell\nme whether it is nonsense.\n\nWhen you branch a file in CVS, CVS notes that the branch exists in the\nfile but doesn't record an author, log message, or timestamp.  The\ncontents of a file just after it is branched are exactly the same as the\ncontents on the parent branch.  Moreover, different files can be added\nto a branch from different parent branches.\n\nThe intended purpose of the \"useless commit\" in the git output of\ncvs2svn is to record the fact that a branch was created, to record\nexactly which files exist on the branch at the time it was created, and\nto record the source branches of the file on the branch.\n\nI imagine that *if* a branch is created with a single parent branch, and\n*if* each and every file from the parent branch is added to the new\nbranch, then it is possible that the \"useless commit\" could be omitted.\n But this decision would require information that cvs2svn doesn't\ncurrently have at that stage of the conversion, and keeping the\nnecessary records would be quite expensive.\n\nBut in the general case, it doesn't seem to me that the commits are\nreally useless.  Am I wrong?  If so, please tell me what should be\nchanged in the git-fast-import data that is output when a branch is\ncreated (e.g., for the main-cvsrepos in the cvs2svn test suite).\n\nRegarding the superfluous vendorbranch parent: vendor branches are an\nobscure CVS feature for tracking upstream sources.  The file contents on\nthe vendorbranch are typically exactly the same as that on trunk, and if\na branch is created while the vendorbranch is active, CVS doesn't record\nwhether the branch's parent was trunk or the vendorbranch.  Haven't yet\nbuilt the heuristics into cvs2svn to make this decision more\nintelligently, so sometimes \"vendorbranch\" is listed as a branch parent\nwhen it could be omitted.\n\n> To sum up, cvs2svn gets the important stuff right, but has some sharp\n> corners you need to watch so you don't put an eye out.\n\nThanks for the feedback!\n\nMichael\n\n[1] http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html\n"},{"id":"55361","messageId":"F1176033-1C6E-43F3-9F47-3BDD5EC88A14@orakel.ntnu.no","threadId":"10206","inReplyTo":"470C3A3A.2070809@alum.mit.edu","subject":"Re: Problem with git-cvsimport","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git-list@orakel.ntnu.no","sentAt":"2007-10-10T13:05:03Z","receivedAt":"2007-10-10T13:05:03Z","isPatch":false,"sender":{"key":"eyvind-git-list@orakel.ntnu.no","avatar":null},"body":"On 10. okt.. 2007, at 04.34, Michael Haggerty wrote:\n\n[...]\n\nThanks for the response!  I should have explained that my goal is to  \nconvince my coworkers that git is worth the effort to learn, and IMO,  \nmaking imported git repositories look as \"clean\" as possible to  \nsomeone familiar with the CVS repository is an important part of  \nthat.  My suggestions and complaints should be seen in that light :)\n\n>> * Tags each get a branch with a single commit, with the actual tag\n>> pointing to that commit.  This makes it harder than necessary to  \n>> figure\n>> out what the history looks like; gitk's default view won't show any\n>> tags, for example, since it only shows the master branch and not the\n>> single-commit tag branches.\n>\n> I just fixed this in cvs2svn trunk r4213.  Now it reuses a single  \n> branch\n> called 'refs/heads/TAG.FIXUP' whenever it needs to make a tag fixup\n> branch, and it resets that branch when done.  (Resetting the tag fixup\n> branch changes it to 0000000000000000000000000000000000000000 but\n> doesn't really delete it; I don't know the ramifications of that but  \n> at\n> least it doesn't appear in gitk output any more.)\n\nGreat!  I'll try this out at the first opportunity.\n\nThe main problem I have with the current branched-tag behaviour is  \nthat nothing exists on the branch to show that a tag is branched off,  \nso no tags are shown at all when running gitk on a single branch.  A  \ngit newbie who is familiar with the CVS repository will probably just  \nassume that tags haven't been imported, which is unfortunate.\n\nTagging the branch point is an obvious solution to that problem, but I  \nwonder if branching for tag fixups could be made optional.  Instead of  \nrepresenting a tag with differences to the commit it's closest to like  \nthis:\n\n     o--*--o--...\n         \\--t\n\n(where \"*\" represents the closest commit on the branch, and \"t\"  \nrepresents the fixup commit), might the following be possible and/or  \ndesirable?\n\n     o--*--t--r--o--...\n\n\"r\" being a commit that reverts the changes in \"t\".\n\nIt might just be me, but I think of a tag as being \"on\" a branch even  \nwhen it has been messed with (sliding, omitting files, etc), and a  \nlinear history preserves that illusion.\n\n>> * Branches all get a useless commit at their branch point.  All  \n>> branches\n>> from the main branch appear to be merged from the vendor branch  \n>> (ie, the\n>> useless commit has the vendor branch as an extra parent), which might\n>> make sense to someone who knows what the vendor branch is for, but  \n>> makes\n>> no sense to me.  This combined with the previous point makes \"gitk\n>> --all\" look needlessly spaghetti-like if you have a slightly  \n>> complicated\n>> CVS history.\n>\n> I assume that the \"useless commit\" that you are referring to is the  \n> one\n> with log message \"This commit was manufactured by cvs2svn to create\n> branch 'BRANCH'.\"  Is that correct?\n\nYes.  And I'm regretting my choice of words already.  \"Unexpected  \ncommit\" would have been better.\n\n> I'm not a git expert, so I don't know whether these commits are in  \n> fact\n> useless.  But let me explain the reason I put them in and you can tell\n> me whether it is nonsense.\n\n[...]\n\nI know barely enough about git (or CVS, for that matter) to be  \ndangerous, but your explanation makes sense to me.\n\n> I imagine that *if* a branch is created with a single parent branch,  \n> and\n> *if* each and every file from the parent branch is added to the new\n> branch, then it is possible that the \"useless commit\" could be  \n> omitted.\n> But this decision would require information that cvs2svn doesn't\n> currently have at that stage of the conversion, and keeping the\n> necessary records would be quite expensive.\n\nRight; that is how I think of a branch, even if CVS doesn't.  To me,  \nthe extra commit is useless because it should be identical to the  \nbranch point commit on the parent branch.  I don't think having an  \nextra commit there is a huge problem, though.\n\n[...]\n\n> Regarding the superfluous vendorbranch parent: vendor branches are an\n> obscure CVS feature for tracking upstream sources.  The file  \n> contents on\n> the vendorbranch are typically exactly the same as that on trunk,  \n> and if\n> a branch is created while the vendorbranch is active, CVS doesn't  \n> record\n> whether the branch's parent was trunk or the vendorbranch.  Haven't  \n> yet\n> built the heuristics into cvs2svn to make this decision more\n> intelligently, so sometimes \"vendorbranch\" is listed as a branch  \n> parent\n> when it could be omitted.\n\nI don't think I've ever seen the vendor branch used for anything but  \nthe initial import (creation) of a repository, and then only because  \nit is a required parameter to \"cvs import\".  Is there any chance you  \ncould add an option to ignore the vendor branch?\n\n> Thanks for the feedback!\n\nThanks for making cvs2svn the best CVS-to-git conversion tool :)  Now  \nif it would only support incremental importing...\n\nEyvind Bernhardsen\n"},{"id":"57612","messageId":"170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com","threadId":"10206","inReplyTo":"F1176033-1C6E-43F3-9F47-3BDD5EC88A14@orakel.ntnu.no","subject":"Re: Problem with git-cvsimport","fromName":"Mike Snitzer","fromEmail":"snitzer@gmail.com","sentAt":"2007-10-30T20:06:09Z","receivedAt":"2007-10-30T20:06:09Z","isPatch":false,"sender":{"key":"snitzer@gmail.com","avatar":null},"body":"On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:\n...\n>\n> Thanks for making cvs2svn the best CVS-to-git conversion tool :)  Now\n> if it would only support incremental importing...\n\nMichael,\n\nI second this question: is there any chance incremental importing will\nbe implemented in cvs2svn?\n\nI've not used cvs2svn much and when I did it was for svn not git; but\ngiven that git-cvsimport is known to mess up your git repo (as Eyvind\npointed out earlier) there doesn't appear to be any reliable tools to\nallow for incrementally importing from cvs to git.\n\nAre others using a tool for reliably importing from cvs to git?\n"},{"id":"57622","messageId":"170fa0d20710301415w40305533o8332419e3b05ece3@mail.gmail.com","threadId":"10206","inReplyTo":"170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com","subject":"Re: Problem with git-cvsimport","fromName":"Mike Snitzer","fromEmail":"snitzer@gmail.com","sentAt":"2007-10-30T21:15:18Z","receivedAt":"2007-10-30T21:15:18Z","isPatch":false,"sender":{"key":"snitzer@gmail.com","avatar":null},"body":"On 10/30/07, Mike Snitzer <snitzer@gmail.com> wrote:\n> On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:\n> ...\n> >\n> > Thanks for making cvs2svn the best CVS-to-git conversion tool :)  Now\n> > if it would only support incremental importing...\n>\n> Michael,\n>\n> I second this question: is there any chance incremental importing will\n> be implemented in cvs2svn?\n>\n> I've not used cvs2svn much and when I did it was for svn not git; but\n> given that git-cvsimport is known to mess up your git repo (as Eyvind\n> pointed out earlier) there doesn't appear to be any reliable tools to\n> allow for incrementally importing from cvs to git.\n>\n> Are others using a tool for reliably importing from cvs to git?\n\nAfter reading the fairly recent \"cvs2svn conversion directly to git\nready for experimentation\" thread it is clear that its doable but\nhasn't been done (seeing as you were looking for volunteers to do it).\n\nSorry for the noise,\nMike\n"},{"id":"57623","messageId":"200710302244.50034.robin.rosenberg.lists@dewire.com","threadId":"10206","inReplyTo":"170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com","subject":"Re: Problem with git-cvsimport","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-30T21:44:48Z","receivedAt":"2007-10-30T21:44:48Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 30 oktober 2007 skrev Mike Snitzer:\n> On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:\n> ...\n> >\n> > Thanks for making cvs2svn the best CVS-to-git conversion tool :)  Now\n> > if it would only support incremental importing...\n> \n> Michael,\n> \n> I second this question: is there any chance incremental importing will\n> be implemented in cvs2svn?\n> \n> I've not used cvs2svn much and when I did it was for svn not git; but\n> given that git-cvsimport is known to mess up your git repo (as Eyvind\n> pointed out earlier) there doesn't appear to be any reliable tools to\n> allow for incrementally importing from cvs to git.\n> \n> Are others using a tool for reliably importing from cvs to git?\n\nI use fromcvs which is *very* fast, and quite memory conservative compared to \nthe others and seems reliable so far (six months). It probably breaks on \nexotic variants of branches though, but I don't have those / don't care about \nthem.\n\nDo not push into the same repo fromcvs works on. I don't understand why, but I \npushed once and *poof* the conversion went bad. \n\nDrawbacks, more dependencies and access to the rcs files is required and tags \nare not converted.\n\n-- robin\n"},{"id":"57654","messageId":"472807A1.8030804@alum.mit.edu","threadId":"10206","inReplyTo":"170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com","subject":"Re: Problem with git-cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2007-10-31T04:42:09Z","receivedAt":"2007-10-31T04:42:09Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Mike Snitzer wrote:\n> On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:\n> ...\n>> Thanks for making cvs2svn the best CVS-to-git conversion tool :)  Now\n>> if it would only support incremental importing...\n> \n> I second this question: is there any chance incremental importing will\n> be implemented in cvs2svn?\n\nUnfortunately, no, there is not much chance that I will implement this.\n I wouldn't be interested in a works-most-of-the-time solution, and a\nreliable solution would take weeks to implement.\n\nIf somebody else wants to implement this feature, I would be happy to\nhelp him get started, answer questions, discuss the design, etc.  Or if\nsomebody wants to sponsor the work, I might be able to justify working\non it myself.  But otherwise, I'm afraid it is unlikely to happen.\n\n> I've not used cvs2svn much and when I did it was for svn not git; but\n> given that git-cvsimport is known to mess up your git repo (as Eyvind\n> pointed out earlier) there doesn't appear to be any reliable tools to\n> allow for incrementally importing from cvs to git.\n\nThat's because it is quite a tricky problem, especially since CVS allows\nhistory to be changed retroactively; for example,\n\n- shift a tag to a different file revision\n\n- add an existing tag to a new file or remove it from an old file\n\n- delete (\"obsolete\") old revisions\n\n- change files from vendor branches to main line of development\n\n- even nastier server-side repository manipulations like deleting an RCS\nfile, renaming a file, etc.\n\nThese things really happen in the topsy-turvy CVS world; indeed, they\nare a part of many organizations' standard workflow.\n\ncvs2svn uses repository-wide information in the heuristics that it uses\nto determine changesets, choose branch parents, fix clock skew, etc.\nTherefore the naive approach of running a full conversion a second time\nand just skipping over the revisions that were handled during the first\nconversion would not even begin to work.  (I believe that this is the\napproach of cvsps, which uses mostly local information to determine\nchangesets.)\n\nI think the correct approach would involve recording the \"frontier\" of\nthe CVS repository, then at the next incremental conversion:\n\n1. compare the current CVS repository to the recorded information\n\n2. emit \"fixup\" changesets to reflect any CVS changes that happened\nbehind the previous \"frontier\".\n\n3. emit changesets to reflect CVS changes beyond the frontier.\n\nIt is step 2 that is IMO the trickiest because it is so open-ended, and\nmodern SCMs don't allow all of the corresponding operations in any\nstraightforward way.  Presumably one would have to prohibit some of the\nnastier CVS tricks and abort the incremental conversion if any are detected.\n\nFurthermore, for many use-cases of incremental conversion the conversion\nwould have to run quickly.  Therefore, the incremental conversion code\nshould be written with a strong emphasis on achieving good performance.\n\nMichael\n"},{"id":"57690","messageId":"fg9t3t$kc3$1@ger.gmane.org","threadId":"10206","inReplyTo":"200710302244.50034.robin.rosenberg.lists@dewire.com","subject":"Re: Problem with git-cvsimport","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2007-10-31T12:40:29Z","receivedAt":"2007-10-31T12:40:29Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"Robin Rosenberg wrote:\n\n> I use fromcvs which is *very* fast, and quite memory conservative compared\n> to the others and seems reliable so far (six months). It probably breaks\n> on exotic variants of branches though, but I don't have those / don't care\n> about them.\n\nI actually use fromcvs for a few repositories, and actually started using it\non repositories where cvsps (and git-cvsimport) fail.\n\n> Drawbacks, more dependencies and access to the rcs files is required and\n> tags are not converted.\n\nMost projects have \"rsyncs\" or \"tarballs\" of their CVS repository available,\nmaking fromcvs possible on most of them.  And CVS tags, well they are about\nas good as CVS $Keywords$.\n"}]}