{"thread":{"id":"8922","subject":"git cvsimport branches not consistent with CVS branches","startedAt":"2007-07-08T00:45:10Z","lastAt":"2007-07-09T04:31:04Z","messageCount":8,"participants":["Gordon Heydon","Brian Downing","Robin Rosenberg","Johannes Schindelin","Steffen Prohaska","Josh Triplett"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46721","messageId":"46903396.1010507@heydon.com.au","threadId":"8922","inReplyTo":null,"subject":"git cvsimport branches not consistent with CVS branches","fromName":"Gordon Heydon","fromEmail":"gordon@heydon.com.au","sentAt":"2007-07-08T00:45:10Z","receivedAt":"2007-07-08T00:45:10Z","isPatch":false,"sender":{"key":"gordon@heydon.com.au","avatar":null},"body":"Hi,\n\nAfter some investigation I found that git cvsimport was not importing \nbranches 100% correctly with CVS.\n\nGit and CVS do branching very differently in that CVS this is done at \nthe file level (like everything else) and git does it repository wide.\n\nSo if I have a CVS repository with the files a, b and c and I branch b \nwith a `cvs tab -b BRANCH test` on the branch test I will just have the \nfile b.\n\nIf I do a git cvsimport on the test branch there will actually be the \nfiles a, b and c\n\nWhat I think needs to happen is that when git cvsimport created the \nbranch in the git repository it needs to delete all files from the \nbranch that were not branched.\n\nThanks in advance.\nGordon.\n"},{"id":"46734","messageId":"20070708054520.GD4087@lavos.net","threadId":"8922","inReplyTo":"46903396.1010507@heydon.com.au","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-07-08T05:45:20Z","receivedAt":"2007-07-08T05:45:20Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Sun, Jul 08, 2007 at 10:45:10AM +1000, Gordon Heydon wrote:\n> After some investigation I found that git cvsimport was not importing \n> branches 100% correctly with CVS.\n> \n> Git and CVS do branching very differently in that CVS this is done at \n> the file level (like everything else) and git does it repository wide.\n> \n> So if I have a CVS repository with the files a, b and c and I branch b \n> with a `cvs tab -b BRANCH test` on the branch test I will just have the \n> file b.\n> \n> If I do a git cvsimport on the test branch there will actually be the \n> files a, b and c\n> \n> What I think needs to happen is that when git cvsimport created the \n> branch in the git repository it needs to delete all files from the \n> branch that were not branched.\n\nI've been vaguely working on Yet Another CVS Importer (an incremental\none; both git-cvsimport (thanks to cvsps) and tailor take about ten\nminutes and a gigabyte of RAM to figure out that nothing has to happen\nwith my repository.  I think I can do better than that).\n\nIn thinking about this case, I think I've decided that you want an\noption on what to do here.  For some repositories you're not going to\ncare about having extra files with the tag, and would greatly prefer\nthat to having to create a branch for each and every tag (assuming you\ncan arrange to have the correct files present otherwise; this isn't\nalways possible.)\n\nFor other cases, you really only want to get the subset of the files\nthat are tagged.  For this, I think the best arrangement would be to\nmake your branch, then make a commit that only deletes the files that\nare not present in the CVS branch, as you said.  Then immediately make\nan empty commit to the mainline (wherever you branched from) merging\nfrom the deletion commit.  Then proceed to commit normally to the\nbranch.  This way, if a user chooses to merge from the branch in Git,\nit won't try to delete a bunch of files in the target branch.  (I'm\nhaving a hard time coming up with a situation where you'd want that\nbehavior assuming the missing files were never tagged in CVS.  A sane\nusage pattern would be to tag the whole repository then \"cvs rm\" the\nfiles you don't want otherwise...)\n\nA fun third case is when a file in CVS doesn't have a branch tag,\nbut then you go and \"cvs add\" a file with the same name in a branch.\nWhat CVS does then is to place the branch tag off the current HEAD.\nI /think/ you can detect this situation by noticing that the date of\nthe HEAD revision and the date of the \"file was created on branch ...\"\nrevision are exactly the same.  You really need to detect this case,\nbecause when this happens there is no real parent relationship between\nthe branch and the branch point.  Since CVS has that \"wait for a second\nto tick\" delay at the end this might even be safe.  Sigh.\n\nDon't get me started about the abomination that is vendor branches.\n\nI /hate/ CVS.\n\n-bcd\n"},{"id":"46745","messageId":"200707081253.06129.robin.rosenberg.lists@dewire.com","threadId":"8922","inReplyTo":"20070708054520.GD4087@lavos.net","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-08T10:53:04Z","receivedAt":"2007-07-08T10:53:04Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 juli 2007 skrev Brian Downing:\n> On Sun, Jul 08, 2007 at 10:45:10AM +1000, Gordon Heydon wrote:\n> > After some investigation I found that git cvsimport was not importing \n> > branches 100% correctly with CVS.\n> > \n> > Git and CVS do branching very differently in that CVS this is done at \n> > the file level (like everything else) and git does it repository wide.\n> > \n> > So if I have a CVS repository with the files a, b and c and I branch b \n> > with a `cvs tab -b BRANCH test` on the branch test I will just have the \n> > file b.\n> > \n> > If I do a git cvsimport on the test branch there will actually be the \n> > files a, b and c\n> > \n> > What I think needs to happen is that when git cvsimport created the \n> > branch in the git repository it needs to delete all files from the \n> > branch that were not branched.\n> \n> I've been vaguely working on Yet Another CVS Importer (an incremental\n> one; both git-cvsimport (thanks to cvsps) and tailor take about ten\n> minutes and a gigabyte of RAM to figure out that nothing has to happen\n> with my repository.  I think I can do better than that).\n\nCorecode's fromcvs is pretty fast and incremental and AFAIK accurate. I had \nplenty problems with cvsimport, but fromcvs keeps in sync with the CVS repo.\nGet  it at http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/ .\n\nIt does not convert regular tags, only branches, however so there is something to \ndo for those that want a complete cvs import.\n\n> In thinking about this case, I think I've decided that you want an\n> option on what to do here.  For some repositories you're not going to\n> care about having extra files with the tag, and would greatly prefer\n> that to having to create a branch for each and every tag (assuming you\n> can arrange to have the correct files present otherwise; this isn't\n> always possible.)\n> \n> For other cases, you really only want to get the subset of the files\n> that are tagged.  For this, I think the best arrangement would be to\n> make your branch, then make a commit that only deletes the files that\n> are not present in the CVS branch, as you said.  Then immediately make\n\nfromcvs drops the files that do not have the branch tag. It is pretty simple to change\nthe behaviour ( http://rosenberg.homelinux.net/gitweb/gitweb.cgi?p=FROMCVS.git;a=commitdiff;h=eb1c159bcc0d79eab182da3d7040ac62b52fd297 )\nalthough this should be a switch and not hard coded.\n\n-- robin\n"},{"id":"46747","messageId":"Pine.LNX.4.64.0707081246040.4248@racer.site","threadId":"8922","inReplyTo":"200707081253.06129.robin.rosenberg.lists@dewire.com","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-08T11:47:16Z","receivedAt":"2007-07-08T11:47:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 8 Jul 2007, Robin Rosenberg wrote:\n\n> Corecode's fromcvs is pretty fast and incremental and AFAIK accurate.\n\nThe only problem is that it is a misnomer: it is not fromcvs, but fromrcs, \nsince you have to have access at the _files_. This is not always \npossible.\n\nCiao,\nDscho\n"},{"id":"46749","messageId":"200707081422.46466.robin.rosenberg.lists@dewire.com","threadId":"8922","inReplyTo":"Pine.LNX.4.64.0707081246040.4248@racer.site","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-08T12:22:46Z","receivedAt":"2007-07-08T12:22:46Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 juli 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Sun, 8 Jul 2007, Robin Rosenberg wrote:\n> \n> > Corecode's fromcvs is pretty fast and incremental and AFAIK accurate.\n> \n> The only problem is that it is a misnomer: it is not fromcvs, but fromrcs, \n> since you have to have access at the _files_. This is not always \n> possible.\n\nA small problem considering that fromcvs works and the other don't. My guess\nis that fromcvs kan be \"fixed\" to do remote access much more easily than cvsimport\ncan be \"fixed\" to import an archive properly.\n\n-- robin\n"},{"id":"46759","messageId":"3BA4D1AE-D5C9-42CB-81B4-38DC3946A966@zib.de","threadId":"8922","inReplyTo":"200707081253.06129.robin.rosenberg.lists@dewire.com","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-08T14:38:53Z","receivedAt":"2007-07-08T14:38:53Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 8, 2007, at 12:53 PM, Robin Rosenberg wrote:\n\n> Corecode's fromcvs is pretty fast and incremental and AFAIK  \n> accurate. I had\n> plenty problems with cvsimport, but fromcvs keeps in sync with the  \n> CVS repo.\n> Get  it at http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/ .\n>\n> It does not convert regular tags, only branches, however so there  \n> is something to\n> do for those that want a complete cvs import.\n\nDid anyone compare\n    * git-cvsimport with cvsps patches from [1]\n    * parsecvs [2]\n    * fromcvs\nand can give a recommendation?\n\nMy experience with plain git-cvsimport (without cvsps patches from [1])\nis that it has a lot of problems. I'd recommend not to use it for\nincremental import and be very suspicious about the git repository\ncreated by git-cvsimport. You need to carefully validate the repository.\nIt's likely that you need to fix imported branches. The trunk seems to\nbe ok.\n\n\tSteffen\n\n[1] http://ydirson.free.fr/en/software/scm/cvsps.html\n[2] http://anongit.freedesktop.org/git/users/keithp/repos/parsecvs.git/\n"},{"id":"46790","messageId":"20070708210217.GE4087@lavos.net","threadId":"8922","inReplyTo":"Pine.LNX.4.64.0707081246040.4248@racer.site","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-07-08T21:02:18Z","receivedAt":"2007-07-08T21:02:18Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Sun, Jul 08, 2007 at 12:47:16PM +0100, Johannes Schindelin wrote:\n> The only problem is that it is a misnomer: it is not fromcvs, but\n> fromrcs, since you have to have access at the _files_. This is not\n> always possible.\n\nFor the problem space I'm interested in (a /fast/ incremental CVS\nimporter) I think access to the RCS files is a must.  You can use inode\nsignatures to know which files you have to look at at all since the last\nrun, and you can abort your parse at the end of the delta section if no\nnew revisions appeared (rather than continuing to parse the deltatext\nsection, the largest part of the file).\n\nFor the repository I'm interested in (work), running a \"real\" cvs update\ntakes two or three minutes on a LAN.  Running a full rlog takes about\n10 or so.  With the tricks above, I can import a single file change in\nseconds instead.  (That includes the time to rsync the CVS repository\nto my local mirror.)\n\nGranted, though, not everyone can get access to the RCS files.\n\n(The name's not really a misnomer though.  There's tons of CVS-specific\ncrap you have to deal with in the RCS file to successfully import it --\nmagic branch revision symbols, horrible vendor branch behavior, etc.)\n\nI will try fromcvs; I hadn't looked at it, since from the documentation\nit looked like it wasn't incremental.\n\n-bcd\n"},{"id":"46820","messageId":"4691BA08.2080107@freedesktop.org","threadId":"8922","inReplyTo":"3BA4D1AE-D5C9-42CB-81B4-38DC3946A966@zib.de","subject":"Re: git cvsimport branches not consistent with CVS branches","fromName":"Josh Triplett","fromEmail":"josh@freedesktop.org","sentAt":"2007-07-09T04:31:04Z","receivedAt":"2007-07-09T04:31:04Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"Steffen Prohaska wrote:\n> On Jul 8, 2007, at 12:53 PM, Robin Rosenberg wrote:\n>> Corecode's fromcvs is pretty fast and incremental and AFAIK  \n>> accurate. I had\n>> plenty problems with cvsimport, but fromcvs keeps in sync with the  \n>> CVS repo.\n>> Get  it at http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/ .\n>>\n>> It does not convert regular tags, only branches, however so there  \n>> is something to\n>> do for those that want a complete cvs import.\n> \n> Did anyone compare\n>     * git-cvsimport with cvsps patches from [1]\n>     * parsecvs [2]\n>     * fromcvs\n> and can give a recommendation?\n> \n> My experience with plain git-cvsimport (without cvsps patches from [1])\n> is that it has a lot of problems. I'd recommend not to use it for\n> incremental import and be very suspicious about the git repository\n> created by git-cvsimport. You need to carefully validate the repository.\n> It's likely that you need to fix imported branches. The trunk seems to\n> be ok.\n\nI've used both parsecvs and git-cvsimport, and I can definitely say from\nexperience that cvsimport badly munges history, and parsecvs seems to handle\nit correctly.  parsecvs does have the limitations that it requires the ,v\nfiles and doesn't work incrementally, making it great for project repository\nconversions and painful for just wanting to use git on a CVS-(mis)managed\nproject.\n\nI've never used fromcvs.\n\nOne idea to mitigate one of the limitations: how about modifying the CVS\nserver to add an extension that supports downloading full ,v files?  CVS has\nhad server extensions in the past, such as for ls/rls.  Once support for this\nextension makes its way out to most CVS servers, this problem goes away.\n\n- Josh Triplett\n"}]}