{"thread":{"id":"3770","subject":"parsecvs tool now creates git repositories","startedAt":"2006-04-02T05:36:28Z","lastAt":"2006-04-04T06:09:02Z","messageCount":22,"participants":["Keith Packard","Jan-Benedict Glaw","Linus Torvalds","Erik Mouw","Jakub Narebski","Jeff King","Martin Langhoff","Anand Kumria","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18210","messageId":"1143956188.2303.39.camel@neko.keithp.com","threadId":"3770","inReplyTo":null,"subject":"parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-02T05:36:28Z","receivedAt":"2006-04-02T05:36:28Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"I've hacked in cheesy system(3) calls to invoke various git tools to\ncreate a git repository from a parsed cvs repository. It's about the\nsame speed as git-cvsimport now.\n\nThe UI is a total disaster, sufficient for testing. You must create an\nAuthors file in the current directory which looks like the git-cvsimport\nauthors file. You must also have a edit-change-log program in your path\nwhich edits the commit message in place. /bin/true will work if you\ndon't need to edit the messages.\n\nI should clearly steal the existing git-cvsimport command line arguments\nand use those.\n\nThis tool successfully, and usefully, imports the X.org xserver CVS\nrepository, along with correctly importing several other repositories\nI've tried. It doesn't quite manage to compute correct branch points for\nthe postgresql CVS repository, so there is clearly work remaining to be\ndone.\n\nCVS - your code's worst nightmare.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18214","messageId":"20060402093906.GH1259@lug-owl.de","threadId":"3770","inReplyTo":"1143956188.2303.39.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-04-02T09:39:06Z","receivedAt":"2006-04-02T09:39:06Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sat, 2006-04-01 21:36:28 -0800, Keith Packard wrote:\n> The UI is a total disaster, sufficient for testing. You must create an\n> Authors file in the current directory which looks like the git-cvsimport\n> authors file. You must also have a edit-change-log program in your path\n> which edits the commit message in place. /bin/true will work if you\n> don't need to edit the messages.\n\nWell, at least this sounds quite promising. I'll give it a run once\nI've arrived back home on the Binutils repository.\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"18231","messageId":"20060402193144.GK1259@lug-owl.de","threadId":"3770","inReplyTo":"20060402093906.GH1259@lug-owl.de","subject":"Re: parsecvs tool now creates git repositories","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-04-02T19:31:44Z","receivedAt":"2006-04-02T19:31:44Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-04-02 11:39:06 +0200, Jan-Benedict Glaw wrote:\n> On Sat, 2006-04-01 21:36:28 -0800, Keith Packard wrote:\n> > The UI is a total disaster, sufficient for testing. You must create an\n> > Authors file in the current directory which looks like the git-cvsimport\n> > authors file. You must also have a edit-change-log program in your path\n> > which edits the commit message in place. /bin/true will work if you\n> > don't need to edit the messages.\n> \n> Well, at least this sounds quite promising. I'll give it a run once\n> I've arrived back home on the Binutils repository.\n\nDoesn't build for me:\n\njbglaw@bixie:~/vax/gittish/parsecvs$ make clean\nrm -f gram.o lex.o parsecvs.o cvsutil.o revlist.o atom.o revcvs.o git.o y.tab.h gram.c parsecvs\njbglaw@bixie:~/vax/gittish/parsecvs$ make\nyacc -d gram.y \nmv -f y.tab.c gram.c\ncc -O0 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -c -o gram.o gram.c\ncc -O0 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -c -o lex.o lex.c\nlex.l: In function ‘yylex’:\nlex.l:69: warning: implicit declaration of function ‘yyget_lineno’\nlex.l:69: warning: nested extern declaration of ‘yyget_lineno’\n: At top level:\n:1747: warning: no previous prototype for ‘yyget_lineno’\n:1756: warning: no previous prototype for ‘yyget_in’\n:1764: warning: no previous prototype for ‘yyget_out’\n:1772: warning: no previous prototype for ‘yyget_leng’\n:1781: warning: no previous prototype for ‘yyget_text’\n:1790: warning: no previous prototype for ‘yyset_lineno’\n:1802: warning: no previous prototype for ‘yyset_in’\n:1807: warning: no previous prototype for ‘yyset_out’\n:1812: warning: no previous prototype for ‘yyget_debug’\n:1817: warning: no previous prototype for ‘yyset_debug’\n:1823: warning: no previous prototype for ‘yylex_destroy’\nlex.l: In function ‘parse_data’:\nlex.l:90: error: ‘yytext_ptr’ undeclared (first use in this function)\nlex.l:90: error: (Each undeclared identifier is reported only once\nlex.l:90: error: for each function it appears in.)\nmake: *** [lex.o] Error 1\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"18258","messageId":"1144037456.2303.92.camel@neko.keithp.com","threadId":"3770","inReplyTo":"20060402193144.GK1259@lug-owl.de","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-03T04:10:56Z","receivedAt":"2006-04-03T04:10:56Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Sun, 2006-04-02 at 21:31 +0200, Jan-Benedict Glaw wrote:\n\n> lex.l: In function ‘parse_data’:\n> lex.l:90: error: ‘yytext_ptr’ undeclared (first use in this function)\n> lex.l:90: error: (Each undeclared identifier is reported only once\n> lex.l:90: error: for each function it appears in.)\n> make: *** [lex.o] Error 1\n\nI think this is a bug in your version of flex; I'm using standard lex\nconventions here. I don't know how to make it work for you.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18265","messageId":"Pine.LNX.4.64.0604022122430.3781@g5.osdl.org","threadId":"3770","inReplyTo":"1144037456.2303.92.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-03T04:38:28Z","receivedAt":"2006-04-03T04:38:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 2 Apr 2006, Keith Packard wrote:\n\n> On Sun, 2006-04-02 at 21:31 +0200, Jan-Benedict Glaw wrote:\n> \n> > lex.l: In function ÿÿparse_dataÿÿ:\n> > lex.l:90: error: ÿÿyytext_ptrÿÿ undeclared (first use in this function)\n> > lex.l:90: error: (Each undeclared identifier is reported only once\n> > lex.l:90: error: for each function it appears in.)\n> > make: *** [lex.o] Error 1\n> \n> I think this is a bug in your version of flex; I'm using standard lex\n> conventions here. I don't know how to make it work for you.\n\nI need something like this to make it work with flex/lex..\n\nThe \"-l\" tells flex to be more traditional.\n\nThe \"clean\" rule is obvious.\n\nAnd the \"yylineno\" is a lot more traditional than yyget_lineno(), which \ndoesn't work for me at all. I think that's some issue with flex' support \nfor re-entrant parsers.\n\nWhether it works after this, I dunno. But at least it compiles.\n\n\t\tLinus\n\n---\ndiff --git a/Makefile b/Makefile\nindex 639353a..c7e04a5 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -4,6 +4,7 @@ GCC_WARNINGS3=-Wnested-externs -fno-stri\n GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)\n CFLAGS=-O0 -g $(GCC_WARNINGS)\n YFLAGS=-d\n+LFLAGS=-l\n \n SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c revlist.c atom.c revcvs.c git.c\n \n@@ -20,4 +21,4 @@ lex.o: lex.c\n y.tab.h: gram.c\n \n clean:\n-\trm -f $(OBJS) y.tab.h gram.c parsecvs\n+\trm -f $(OBJS) y.tab.h gram.c parsecvs lex.c\ndiff --git a/lex.l b/lex.l\nindex 39cafb0..c7833a4 100644\n--- a/lex.l\n+++ b/lex.l\n@@ -65,8 +65,7 @@ parse_data (int save);\n \\t\t\t\t\t;\n \\n\t\t\t\t;\n .\t\t\t\t{ \n-\t\t\t\t fprintf (stderr, \"%s: (%d) ignoring %c\\n\", \n-\t\t\t\t\t yyfilename, yyget_lineno (),\n+\t\t\t\t fprintf (stderr, \"%s: (%d) ignoring %c\\n\", yyfilename, yylineno,\n \t\t\t\t\t yytext[0]);\n \t\t\t\t}\n %%\n@@ -146,8 +145,7 @@ lex_date (cvs_number *n)\n \td = mktime (&tm);\n \tif (d == 0) {\n \t int i;\n-\t fprintf (stderr, \"%s: (%d) unparsable date: \", yyfilename,\n-\t\t yyget_lineno ());\n+\t fprintf (stderr, \"%s: (%d) unparsable date: \", yyfilename, yylineno);\n \t for (i = 0; i < n->c; i++) {\n \t\tif (i) fprintf (stderr, \".\");\n \t\tfprintf (stderr, \"%d\", n->n[i]);"},{"id":"18267","messageId":"20060403072554.GN1259@lug-owl.de","threadId":"3770","inReplyTo":"1144037456.2303.92.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-04-03T07:25:54Z","receivedAt":"2006-04-03T07:25:54Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-04-02 21:10:56 -0700, Keith Packard wrote:\n> On Sun, 2006-04-02 at 21:31 +0200, Jan-Benedict Glaw wrote:\n> > lex.l: In function ‘parse_data’:\n> > lex.l:90: error: ‘yytext_ptr’ undeclared (first use in this function)\n> > lex.l:90: error: (Each undeclared identifier is reported only once\n> > lex.l:90: error: for each function it appears in.)\n> > make: *** [lex.o] Error 1\n> \n> I think this is a bug in your version of flex; I'm using standard lex\n> conventions here. I don't know how to make it work for you.\n\nIt compiles for me with this patch (thanks to Linus for the hint):\n\ndiff --git a/Makefile b/Makefile\nindex 639353a..b8f5014 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -3,7 +3,8 @@ GCC_WARNINGS2=-Wmissing-prototypes -Wmis\n GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing\n GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)\n CFLAGS=-O0 -g $(GCC_WARNINGS)\n-YFLAGS=-d\n+YFLAGS=-d -l\n+LFLAGS=-l\n \n SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c revlist.c atom.c revcvs.c git.c\n \n\nWould you please verify that it doesn't break things for you?\n\nThanks, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"18278","messageId":"20060403135834.GD16823@harddisk-recovery.com","threadId":"3770","inReplyTo":"20060403072554.GN1259@lug-owl.de","subject":"Re: parsecvs tool now creates git repositories","fromName":"Erik Mouw","fromEmail":"erik@harddisk-recovery.com","sentAt":"2006-04-03T13:58:34Z","receivedAt":"2006-04-03T13:58:34Z","isPatch":false,"sender":{"key":"erik@harddisk-recovery.com","avatar":null},"body":"On Mon, Apr 03, 2006 at 09:25:54AM +0200, Jan-Benedict Glaw wrote:\n> On Sun, 2006-04-02 21:10:56 -0700, Keith Packard wrote:\n> > I think this is a bug in your version of flex; I'm using standard lex\n> > conventions here. I don't know how to make it work for you.\n> \n> It compiles for me with this patch (thanks to Linus for the hint):\n> \n> diff --git a/Makefile b/Makefile\n\n[...]\n\n> Would you please verify that it doesn't break things for you?\n\nAlmost there. I applied your patch and ran \"make clean\", but the\nMakefile forgets to remove lex.c. Here's an updated patch:\n\ndiff --git a/Makefile b/Makefile\nindex 639353a..5651e70 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -3,7 +3,8 @@ GCC_WARNINGS2=-Wmissing-prototypes -Wmis\n GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing\n GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)\n CFLAGS=-O0 -g $(GCC_WARNINGS)\n-YFLAGS=-d\n+YFLAGS=-d -l\n+LFLAGS=-l\n \n SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c revlist.c atom.c revcvs.c git.c\n \n@@ -20,4 +21,4 @@ lex.o: lex.c\n y.tab.h: gram.c\n \n clean:\n-\trm -f $(OBJS) y.tab.h gram.c parsecvs\n+\trm -f $(OBJS) y.tab.h gram.c lex.c parsecvs\n\n\n\nIt compiles! Ship it! ;-)\n\n\nErik\n\n-- \n+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --\n| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands\n"},{"id":"18279","messageId":"20060403140348.GE16823@harddisk-recovery.com","threadId":"3770","inReplyTo":"1143956188.2303.39.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Erik Mouw","fromEmail":"erik@harddisk-recovery.com","sentAt":"2006-04-03T14:03:48Z","receivedAt":"2006-04-03T14:03:48Z","isPatch":false,"sender":{"key":"erik@harddisk-recovery.com","avatar":null},"body":"On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:\n> The UI is a total disaster, sufficient for testing. You must create an\n> Authors file in the current directory which looks like the git-cvsimport\n> authors file. You must also have a edit-change-log program in your path\n> which edits the commit message in place. /bin/true will work if you\n> don't need to edit the messages.\n> \n> I should clearly steal the existing git-cvsimport command line arguments\n> and use those.\n\nWhat is the current way to use it? I get the impression it reads raw ,v\nfiles, but how do I get along with a remote CVS repository?\n\n\nErik\n\n-- \n+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --\n| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands\n"},{"id":"18280","messageId":"e0rb0j$ml9$1@sea.gmane.org","threadId":"3770","inReplyTo":"20060403140348.GE16823@harddisk-recovery.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-03T14:21:10Z","receivedAt":"2006-04-03T14:21:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Mouw wrote:\n\n> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:\n>> The UI is a total disaster, sufficient for testing. You must create an\n>> Authors file in the current directory which looks like the git-cvsimport\n>> authors file. You must also have a edit-change-log program in your path\n>> which edits the commit message in place. /bin/true will work if you\n>> don't need to edit the messages.\n>> \n>> I should clearly steal the existing git-cvsimport command line arguments\n>> and use those.\n> \n> What is the current way to use it? I get the impression it reads raw ,v\n> files, but how do I get along with a remote CVS repository?\n\n>From the comments on #git, parsecvs reads raw ,v files for creating history\ntree, then uses 'cvs co ...' for getting the contents.\n\nIf you have access to remote CVS repository, it was suggested to use either\ncvsclone or cvsup.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18285","messageId":"1144075047.2303.97.camel@neko.keithp.com","threadId":"3770","inReplyTo":"20060403140348.GE16823@harddisk-recovery.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-03T14:37:27Z","receivedAt":"2006-04-03T14:37:27Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Mon, 2006-04-03 at 16:03 +0200, Erik Mouw wrote:\n> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:\n> > The UI is a total disaster, sufficient for testing. You must create an\n> > Authors file in the current directory which looks like the git-cvsimport\n> > authors file. You must also have a edit-change-log program in your path\n> > which edits the commit message in place. /bin/true will work if you\n> > don't need to edit the messages.\n> > \n> > I should clearly steal the existing git-cvsimport command line arguments\n> > and use those.\n> \n> What is the current way to use it? I get the impression it reads raw ,v\n> files, but how do I get along with a remote CVS repository?\n\nYou can't. You need to create a local copy of the repository. There is a\ntool which can do that using the cvs protocol, but I don't recall the\nname.\n\nIt turns out that parsing the ,v files directly is both faster and more\naccurate than attempting to interpret the output of cvs log.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18287","messageId":"1144075148.2303.100.camel@neko.keithp.com","threadId":"3770","inReplyTo":"e0rb0j$ml9$1@sea.gmane.org","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-03T14:39:08Z","receivedAt":"2006-04-03T14:39:08Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Mon, 2006-04-03 at 16:21 +0200, Jakub Narebski wrote:\n\n> From the comments on #git, parsecvs reads raw ,v files for creating history\n> tree, then uses 'cvs co ...' for getting the contents.\n\nIt's not using cvs co, it's using the rcs 'co' command. I will probably\nfix it to just generate the files directly as that will be a lot faster.\nIf there was a git command to create blobs directly from file contents,\nit would be faster still as I could create all of the blobs for a\nparticular file in one pass and then just build trees in the index out\nof those.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18289","messageId":"20060403153233.GA6631@sigio.intra.peff.net","threadId":"3770","inReplyTo":"1144075047.2303.97.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-04-03T15:32:33Z","receivedAt":"2006-04-03T15:32:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 03, 2006 at 07:37:27AM -0700, Keith Packard wrote:\n\n> You can't. You need to create a local copy of the repository. There is a\n> tool which can do that using the cvs protocol, but I don't recall the\n> name.\n\nI believe you're thinking of CVSSuck:\n http://cvs.m17n.org/~akr/cvssuck/\n\n-Peff\n"},{"id":"18294","messageId":"1144083282.2303.102.camel@neko.keithp.com","threadId":"3770","inReplyTo":"20060403072554.GN1259@lug-owl.de","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-03T16:54:42Z","receivedAt":"2006-04-03T16:54:42Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:\n\n> -YFLAGS=-d\n> +YFLAGS=-d -l\n> +LFLAGS=-l\n\nWorks for me too; thanks for the fix.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18305","messageId":"1144102753.2303.121.camel@neko.keithp.com","threadId":"3770","inReplyTo":"1144083282.2303.102.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-03T22:19:13Z","receivedAt":"2006-04-03T22:19:13Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Mon, 2006-04-03 at 09:54 -0700, Keith Packard wrote:\n> On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:\n> \n> > -YFLAGS=-d\n> > +YFLAGS=-d -l\n> > +LFLAGS=-l\n> \n> Works for me too; thanks for the fix.\n\nWell, -l *kinda* works; it places a limit on the maximum token size.\nAnd, unlike 'lex', 'flex' places all input into the token buffer, even\nif handled outside the usual lexer loop. So, my external function that\nsucked up file contents was losing.\n\nI switched it over to doing one-at-a-time reads from the input file, now\nthe external data function can directly use stdio. This eliminates all\ncalls to 'input' and 'unput' which should make it work for everyone now.\n\nflex -- it's like lex, except less flexible.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18309","messageId":"46a038f90604031538x3c94d86ap9f1400427513a3a7@mail.gmail.com","threadId":"3770","inReplyTo":"1143956188.2303.39.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-04-03T22:38:12Z","receivedAt":"2006-04-03T22:38:12Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Keith,\n\nLooks nifty. Though I thought you'd go for writing a smarter cvsps, so\nthat git-cvsimport could take advantage of it.\n\nLooks like I'll have to brush up on my C to get to play... :-(\n\n\n\nm\n"},{"id":"18317","messageId":"pan.2006.04.04.00.55.35.724626@progsoc.org","threadId":"3770","inReplyTo":"20060403140348.GE16823@harddisk-recovery.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Anand Kumria","fromEmail":"wildfire@progsoc.org","sentAt":"2006-04-04T00:55:37Z","receivedAt":"2006-04-04T00:55:37Z","isPatch":false,"sender":{"key":"wildfire@progsoc.org","avatar":null},"body":"On Mon, 03 Apr 2006 16:03:48 +0200, Erik Mouw wrote:\n\n> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:\n>> The UI is a total disaster, sufficient for testing. You must create an\n>> Authors file in the current directory which looks like the git-cvsimport\n>> authors file. You must also have a edit-change-log program in your path\n>> which edits the commit message in place. /bin/true will work if you\n>> don't need to edit the messages.\n>> \n>> I should clearly steal the existing git-cvsimport command line arguments\n>> and use those.\n> \n> What is the current way to use it? I get the impression it reads raw ,v\n> files, but how do I get along with a remote CVS repository?\n\ncvsclone, recently released, might be what you are after.\n\nI've only used it on my own CVS repositories so I've no idea just how hard\nit hits the remote side.\n\n\n\nAnand\n"},{"id":"18320","messageId":"1144116459.2303.129.camel@neko.keithp.com","threadId":"3770","inReplyTo":"46a038f90604031538x3c94d86ap9f1400427513a3a7@mail.gmail.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-04T02:07:39Z","receivedAt":"2006-04-04T02:07:39Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Tue, 2006-04-04 at 10:38 +1200, Martin Langhoff wrote:\n\n> Looks nifty. Though I thought you'd go for writing a smarter cvsps, so\n> that git-cvsimport could take advantage of it.\n\nOnce I had the change set information sitting in memory, it was far\neasier to just generate the appropriate git commands than attempt to\nrecreate the cvsps output format...\n\n> Looks like I'll have to brush up on my C to get to play... :-(\n\nTrust me, it wasn't because I wanted to replace git-cvsimport; it's\nsolely that cvsps was generating complete garbage for most of my\nrepositories.\n\nMy new tool isn't perfect yet; it isn't getting exactly the expected\nanswers for the postgresql repository, but it's working perfectly for my\nX server one.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18322","messageId":"46a038f90604031916r4651b572lb9bae4c5a3d47bc9@mail.gmail.com","threadId":"3770","inReplyTo":"1144116459.2303.129.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-04-04T02:16:32Z","receivedAt":"2006-04-04T02:16:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/4/06, Keith Packard wrote:\n> Trust me, it wasn't because I wanted to replace git-cvsimport; it's\n> solely that cvsps was generating complete garbage for most of my\n> repositories.\n\nOh, I don't mind -- we may as well bury cvsimport but I can't do C\nlike I can do Perl, and I surely want to help on this one.\n\n> My new tool isn't perfect yet; it isn't getting exactly the expected\n> answers for the postgresql repository, but it's working perfectly for my\n> X server one.\n\nMeh, had you done it in Perl, I'd be helping you with the Pg repo,\nattic files and ensuring that files created on a branch and then put\ninto HEAD are handled gracefully. (But you'll get Linus' and Junio's\nattention. Smarty cookie.)\n\nDoes it run incrementally? Can it discover non-binary files and pass -kk?\n\ncheers,\n\n\nmartin\n"},{"id":"18323","messageId":"1144117473.2303.132.camel@neko.keithp.com","threadId":"3770","inReplyTo":"46a038f90604031916r4651b572lb9bae4c5a3d47bc9@mail.gmail.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-04T02:24:33Z","receivedAt":"2006-04-04T02:24:33Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Tue, 2006-04-04 at 14:16 +1200, Martin Langhoff wrote:\n\n> Meh, had you done it in Perl, I'd be helping you with the Pg repo,\n> attic files and ensuring that files created on a branch and then put\n> into HEAD are handled gracefully. (But you'll get Linus' and Junio's\n> attention. Smarty cookie.)\n\nI think those parts are working correctly, I've had plenty of examples\nof that kind of adventure.\n\n> Does it run incrementally? Can it discover non-binary files and pass -kk?\n\nIt doesn't run incrementally, and it unconditionally passes -kk. It's\ncurrently using rcs to check out versions of the files, so it should\ndeal with binary content as well as rcs does. Is there something magic I\nneed to do here? Like for DOS?\n\n-- \nkeith.packard@intel.com\n"},{"id":"18324","messageId":"46a038f90604031942w779894b8p5ef221482a70a301@mail.gmail.com","threadId":"3770","inReplyTo":"1144117473.2303.132.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-04-04T02:42:43Z","receivedAt":"2006-04-04T02:42:43Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/4/06, Keith Packard wrote:\n> On Tue, 2006-04-04 at 14:16 +1200, Martin Langhoff wrote:\n>\n> > Meh, had you done it in Perl, I'd be helping you with the Pg repo,\n> > attic files and ensuring that files created on a branch and then put\n> > into HEAD are handled gracefully. (But you'll get Linus' and Junio's\n> > attention. Smarty cookie.)\n>\n> I think those parts are working correctly, I've had plenty of examples\n> of that kind of adventure.\n\nCool. What's the matter with the Pg repo? (Where can I get hold of that repo?)\n\n> > Does it run incrementally? Can it discover non-binary files and pass -kk?\n>\n> It doesn't run incrementally, and it unconditionally passes -kk. It's\n\nI thought that the .git-cvs directory it created was to be able to run\nincrementally (btw, I think it's fair game to create subdirs inside\n.git for this kind of status-tracking). And passing -kk uncoditionally\nis destructive in some cases (I know... git-cvsimport does it, and I\nwant to fix that). If you can ask rcs about the mode if the file and\nnot pass -kk for binary files...\n\n> currently using rcs to check out versions of the files, so it should\n> deal with binary content as well as rcs does. Is there something magic I\n> need to do here? Like for DOS?\n\nWe'll let DOS take care of itself ;)\n\n\n\nm\n"},{"id":"18325","messageId":"1144122709.2303.153.camel@neko.keithp.com","threadId":"3770","inReplyTo":"46a038f90604031942w779894b8p5ef221482a70a301@mail.gmail.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-04-04T03:51:49Z","receivedAt":"2006-04-04T03:51:49Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Tue, 2006-04-04 at 14:42 +1200, Martin Langhoff wrote:\n\n> Cool. What's the matter with the Pg repo? (Where can I get hold of that repo?)\n\nAs usual, the detection of branch locations is messed up.\n\nThe postgresql CVS tree is available at:\n\n rsync anoncvs.postgresql.org::pgsql-cvs/* postgresql.cvs\n\nIt's a fairly hefty 300M.\n\n> > > Does it run incrementally? Can it discover non-binary files and pass -kk?\n> >\n> > It doesn't run incrementally, and it unconditionally passes -kk. It's\n> \n> I thought that the .git-cvs directory it created was to be able to run\n> incrementally (btw, I think it's fair game to create subdirs inside\n> .git for this kind of status-tracking). And passing -kk uncoditionally\n> is destructive in some cases (I know... git-cvsimport does it, and I\n> want to fix that). If you can ask rcs about the mode if the file and\n> not pass -kk for binary files...\n\nnah, the .git-cvs directory is purely for debugging; I leave the various\ncommand outputs there so I can see what went wrong.\n\nI don't really have a good idea of how we'd do this process\nincrementally; that's not something I am personally interested in\neither, I want to run screaming from CVS as fast as I can at this point.\n\n> > currently using rcs to check out versions of the files, so it should\n> > deal with binary content as well as rcs does. Is there something magic I\n> > need to do here? Like for DOS?\n> \n> We'll let DOS take care of itself ;)\n\nI did discover that rcs has less sophisticated keyword substitution than\ncvs; not having any ability to customize stuff.\n\nI guess we need to figure out when to pass -ko and when to pass -kk. The\nother alternative I'd like to get around to trying is to directly\ngenerate all of the revision contents from the ,v file.\n\nI've just changed parsecvs to generate blobs for every revision in\neach ,v file right after they're read in; putting the necessary code\nright into parsecvs should be reasonably straightforward; we don't need\nthe multi-patch logic as we do want to compute each intermediate version\nof the file.\n\nWith the blobs all generated, the rest of the operation is a simple\nmatter of building suitable indices and creating commits out of them.\nThat's a reasonably fast operation now as it doesn't manipulate any file\ncontents. Plus, I can do all of the index operations using a single\ngit-update-index command, so I eliminate a pile of forking.\n\nDoing the file revision generation in-line would allow us to eliminate\nmost of the remaining forks; we'd run one git-hash-object per file (or\nso), then a git-update-index, git-write-tree and git-commit-tree per\nresulting commit.\n\n-- \nkeith.packard@intel.com\n"},{"id":"18326","messageId":"7vodzhc1oh.fsf@assigned-by-dhcp.cox.net","threadId":"3770","inReplyTo":"1144122709.2303.153.camel@neko.keithp.com","subject":"Re: parsecvs tool now creates git repositories","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-04T06:09:02Z","receivedAt":"2006-04-04T06:09:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Keith Packard writes:\n\n> I've just changed parsecvs to generate blobs for every revision in\n> each ,v file right after they're read in; putting the necessary code\n> right into parsecvs should be reasonably straightforward; we don't need\n> the multi-patch logic as we do want to compute each intermediate version\n> of the file.\n\nIf you want to go really fast without extra fork, are writing it\nin C, and have the data for blob in core, you could link with\nlibgit.a and call write_sha1_file() yourself:\n\n\tunsigned char sha1[20];\n void *buf;\n unsigned long len;\n\n\twrite_sha1_file(buf, len, \"blob\", sha1);\n\ninstead of forking \"hash-object -w\". You feed your blob data\nin buf, with its length in len, and you will get the blob object\nname back in sha1[]. buf is owned by you and after\nwrite_sha1_file() returns it is safe for you to scribble over it\nor free() it. sha1[] stores binary object name (20 bytes, not\n40-byte hexadecimal), and you can use the helper function\nsha1_to_hex() if you need a hex representation:\n\n\tchar *sha1_to_hex(sha1)\n\nwhich returns a pointer to a static buffer that is valid until\nnext call to sha1_to_hex(), so you need to strdup it if you want\nto retain it.\n"}]}