{"thread":{"id":"4370","subject":"Importing Mozilla CVS into git","startedAt":"2006-06-01T22:21:54Z","lastAt":"2006-06-07T18:29:20Z","messageCount":47,"participants":["Jon Smirl","Keith Packard","Linus Torvalds","Shawn Pearce","Martin Langhoff","Pavel Roskin","Junio C Hamano","Johannes Schindelin","Robin Rosenberg (list subscriber)","Bertrand Jacquin","Jakub Narebski","Yakov Lerner","Igor Bukanov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21065","messageId":"9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com","threadId":"4370","inReplyTo":null,"subject":"Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-01T22:21:54Z","receivedAt":"2006-06-01T22:21:54Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"I've been working on importing the Mozilla CVS into git for the last\nfew days. I've fixed up parsecvs so that it can parse the entire\nrepository without errors. Now I'm running into problems because there\nare over 300 branches.\n\nI just run into a problem with git show-branch. Mozilla CVS has a lot\nmore than 29 refs, is this something that can be expanded?\n\nIs anyone interested in helping out with this? My knowledge of git and\nCVS is limited. Mozilla CVS is about 3GB and it is available via\nrsync. I can post the parsecvs changes if wanted.\n\nrsync -az cvs-mirror.mozilla.org::mozilla ~/mozilla/cvs-mirror\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21067","messageId":"1149204044.27695.38.camel@neko.keithp.com","threadId":"4370","inReplyTo":"9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-01T23:20:44Z","receivedAt":"2006-06-01T23:20:44Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Thu, 2006-06-01 at 18:21 -0400, Jon Smirl wrote:\n\n> Is anyone interested in helping out with this? My knowledge of git and\n> CVS is limited. Mozilla CVS is about 3GB and it is available via\n> rsync. I can post the parsecvs changes if wanted.\n\nYes, please post parsecvs changes; I've been able to import several\nrepositories of this size without problems (given sufficient memory).\n\n-- \nkeith.packard@intel.com\n"},{"id":"21070","messageId":"Pine.LNX.4.64.0606011643290.5498@g5.osdl.org","threadId":"4370","inReplyTo":"9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-01T23:48:29Z","receivedAt":"2006-06-01T23:48:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 1 Jun 2006, Jon Smirl wrote:\n>\n> I've been working on importing the Mozilla CVS into git for the last\n> few days. I've fixed up parsecvs so that it can parse the entire\n> repository without errors. Now I'm running into problems because there\n> are over 300 branches.\n> \n> I just run into a problem with git show-branch. Mozilla CVS has a lot\n> more than 29 refs, is this something that can be expanded?\n\nHmm.. Any reason you care about \"show-branch --all\" in particular?\n\nThe algorithm used for show-branch really doesn't scale well, it needs one \nbit per commit per branch, and I didn't realize anybody could ever really \ncare.\n\n\t\tLinus\n"},{"id":"21072","messageId":"9e4733910606011755n29a149f2m1409c5a23888f1c5@mail.gmail.com","threadId":"4370","inReplyTo":"1149204044.27695.38.camel@neko.keithp.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-02T00:55:49Z","receivedAt":"2006-06-02T00:55:49Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"With the attached patch you can parse the entire Mozilla tree. The\ntree has over 100,000 files in it and about 300 branches.\n\nI ran this overnight and it failed with out of memory on a 1GB machine\nwith 1GB swap. If failed in the branch processing, the parse phase\nsucceeded.\n\nHow much memory does something like this need?\n\nIf you want to quickly check out the branch processing problems use\nrsync to pull down just a copy of repository files.\n\nI am getting 1000s of warnings like these and I haven't figured out why yet.\n\nWarning: ../mozilla/mozilla/build/mac/build_scripts/Attic/MozillaCheckoutList.txt,v:\nunnamed branch from master\nWarning: ../mozilla/mozilla/build/unix/run-mozilla.sh,v: unnamed\nbranch from master\nWarning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master of 99855\nWarning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master\nWarning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master99855\nWarning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master\nWarning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.cp,v:\nunnamed branch from master\nWarning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.h,v:\nunnamed branch from master\nWarning: ../mozilla/mozilla/cmd/macfe/central/Attic/msv2dsk.cp,v:\nunnamed branch from master\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21073","messageId":"9e4733910606011759t7c828a50gc4a6b45d92d2b344@mail.gmail.com","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606011643290.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-02T00:59:17Z","receivedAt":"2006-06-02T00:59:17Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/1/06, Linus Torvalds wrote:\n>\n>\n> On Thu, 1 Jun 2006, Jon Smirl wrote:\n> >\n> > I've been working on importing the Mozilla CVS into git for the last\n> > few days. I've fixed up parsecvs so that it can parse the entire\n> > repository without errors. Now I'm running into problems because there\n> > are over 300 branches.\n> >\n> > I just run into a problem with git show-branch. Mozilla CVS has a lot\n> > more than 29 refs, is this something that can be expanded?\n>\n> Hmm.. Any reason you care about \"show-branch --all\" in particular?\n>\n> The algorithm used for show-branch really doesn't scale well, it needs one\n> bit per commit per branch, and I didn't realize anybody could ever really\n> care.\n\nI was trying to use it to figure out what was wrong with the branch\nprocessing in parsecvs. It doesn't have to be fixed. show-branch --all\nfails with same 29 tag limit.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21074","messageId":"Pine.LNX.4.64.0606011809401.5498@g5.osdl.org","threadId":"4370","inReplyTo":"9e4733910606011759t7c828a50gc4a6b45d92d2b344@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-02T01:11:11Z","receivedAt":"2006-06-02T01:11:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 1 Jun 2006, Jon Smirl wrote:\n> \n> I was trying to use it to figure out what was wrong with the branch\n> processing in parsecvs. It doesn't have to be fixed. show-branch --all\n> fails with same 29 tag limit.\n\nYou're much better off using \"gitk --all\" if you want to see the result, \nthe \"show-branch\" this is really broken. It is using the old algorithm \nthat we used to use for \"git-rev-tree\", and got rid of about a year ago \nthere in favour of git-rev-list ;)\n\n\t\t\tLinus\n"},{"id":"21075","messageId":"1149214075.5521.31.camel@neko.keithp.com","threadId":"4370","inReplyTo":"9e4733910606011755n29a149f2m1409c5a23888f1c5@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-02T02:07:55Z","receivedAt":"2006-06-02T02:07:55Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Thu, 2006-06-01 at 20:55 -0400, Jon Smirl wrote:\n> With the attached patch you can parse the entire Mozilla tree. The\n> tree has over 100,000 files in it and about 300 branches.\n\nthat's good news.\n\n> I ran this overnight and it failed with out of memory on a 1GB machine\n> with 1GB swap. If failed in the branch processing, the parse phase\n> succeeded.\n\nyeah, parsecvs has some internal storage inefficiencies which need to be\naddressed. In particular, every commit has a pointer to the related\nrevision of every file in the commit. Much like git used to store every\nfilename in the commit object and was changed to share common directory\ncontents, parsecvs should be fixed to do the same.\n\n> How much memory does something like this need?\n\nIt's basically 4 * nrev * nfile bytes on a 32-bit machine, multiply by 2\nfor a 64-bit machine.\n\n> If you want to quickly check out the branch processing problems use\n> rsync to pull down just a copy of repository files.\n> \n> I am getting 1000s of warnings like these and I haven't figured out why yet.\n> \n> Warning: ../mozilla/mozilla/build/mac/build_scripts/Attic/MozillaCheckoutList.txt,v:\n> unnamed branch from master\n> Warning: ../mozilla/mozilla/build/unix/run-mozilla.sh,v: unnamed\n> branch from master\n> Warning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master of 99855\n> Warning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master\n> Warning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master99855\n> Warning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master\n> Warning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.cp,v:\n> unnamed branch from master\n> Warning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.h,v:\n> unnamed branch from master\n> Warning: ../mozilla/mozilla/cmd/macfe/central/Attic/msv2dsk.cp,v:\n> unnamed branch from master\n\nyeah, these happen when vendor branches go awry. I'll pull the\nrepository and take a look. X.org had similar 'issues' as the current\nCVS repo was built by merging mesa, XFree86 and X.org together in a\nrather haphazard fashion.\n\n-- \nkeith.packard@intel.com\n"},{"id":"21077","messageId":"9e4733910606011936i725e8eb2h8c2357f3688da43e@mail.gmail.com","threadId":"4370","inReplyTo":"1149214075.5521.31.camel@neko.keithp.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-02T02:36:25Z","receivedAt":"2006-06-02T02:36:25Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/1/06, Keith Packard wrote:\n> yeah, these happen when vendor branches go awry. I'll pull the\n> repository and take a look. X.org had similar 'issues' as the current\n> CVS repo was built by merging mesa, XFree86 and X.org together in a\n> rather haphazard fashion.\n\nLet me know what you find. Converting this without rewriting parsecvs\nlooks to be beyond the capacity of my home machine. I'm sure you have\naccess to giant machines at Intel.\n\nDid I see that you can use CVS client tools to manipulate a git\nrepository? Mozilla has a lot of users on other OSes besides Linux. It\nwould be nice to change the core server over to git and leave these\nother users running their existing tools.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21078","messageId":"20060602025644.GA5181@spearce.org","threadId":"4370","inReplyTo":"9e4733910606011936i725e8eb2h8c2357f3688da43e@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-06-02T02:56:44Z","receivedAt":"2006-06-02T02:56:44Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jon Smirl wrote:\n> Did I see that you can use CVS client tools to manipulate a git\n> repository? Mozilla has a lot of users on other OSes besides Linux. It\n> would be nice to change the core server over to git and leave these\n> other users running their existing tools.\n\nYes. Look at git-cvsserver (ships standard as part of GIT).\nIt should also be faster than the original CVS server. :-)\n\n-- \nShawn.\n"},{"id":"21079","messageId":"1149219593.5521.34.camel@neko.keithp.com","threadId":"4370","inReplyTo":"9e4733910606011936i725e8eb2h8c2357f3688da43e@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-02T03:39:53Z","receivedAt":"2006-06-02T03:39:53Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Thu, 2006-06-01 at 22:36 -0400, Jon Smirl wrote:\n\n> Did I see that you can use CVS client tools to manipulate a git\n> repository? Mozilla has a lot of users on other OSes besides Linux. It\n> would be nice to change the core server over to git and leave these\n> other users running their existing tools.\n\nIt's possible, but I would not encourage people to use this for anything\nother than passive monitoring of the code; CVS semantics are really too\nweak to express the capabilities of the git repository, so changes made\nthrough CVS will lose information.\n\nGit runs fine on Windows these days; asking people to use reasonable\ntools to contribute to the project doesn't seem crazy to me.\n\n-- \nkeith.packard@intel.com\n"},{"id":"21080","messageId":"9e4733910606012047h727a25f1vb367c880f8933c4e@mail.gmail.com","threadId":"4370","inReplyTo":"1149219593.5521.34.camel@neko.keithp.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-02T03:47:06Z","receivedAt":"2006-06-02T03:47:06Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/1/06, Keith Packard wrote:\n> Git runs fine on Windows these days; asking people to use reasonable\n> tools to contribute to the project doesn't seem crazy to me.\n\nWIndows, Mac, Solaris and Linux will cover most Firefox developers.\nIs git to go on those platforms? Is WIndows native or cygwin?\n\nThere are a few more people on weird platforms that will need a solution.\nAre perl and shell script still a requirement?\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21081","messageId":"1149220518.5521.43.camel@neko.keithp.com","threadId":"4370","inReplyTo":"9e4733910606012047h727a25f1vb367c880f8933c4e@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-02T03:55:18Z","receivedAt":"2006-06-02T03:55:18Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Thu, 2006-06-01 at 23:47 -0400, Jon Smirl wrote:\n> On 6/1/06, Keith Packard wrote:\n> > Git runs fine on Windows these days; asking people to use reasonable\n> > tools to contribute to the project doesn't seem crazy to me.\n> \n> WIndows, Mac, Solaris and Linux will cover most Firefox developers.\n> Is git to go on those platforms? Is WIndows native or cygwin?\n\nI think the windows stuff may still be cygwin, but Mac and Solaris work\nfine with the git, of course. It's just simple posix code, after all\n\n> There are a few more people on weird platforms that will need a solution.\n> Are perl and shell script still a requirement?\n\nYeah, quite a bit of both of those still. Less over time as people\nfigure out that C code is generally easier to fix than a nasty\ncombination of C code, shell scripts and perl line noise.\n\n-- \nkeith.packard@intel.com\n"},{"id":"21082","messageId":"9e4733910606012100s7ace4721le6fbfbcaadfb6c43@mail.gmail.com","threadId":"4370","inReplyTo":"1149220518.5521.43.camel@neko.keithp.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-02T04:00:37Z","receivedAt":"2006-06-02T04:00:37Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/1/06, Keith Packard wrote:\n> On Thu, 2006-06-01 at 23:47 -0400, Jon Smirl wrote:\n> > On 6/1/06, Keith Packard wrote:\n> > > Git runs fine on Windows these days; asking people to use reasonable\n> > > tools to contribute to the project doesn't seem crazy to me.\n> >\n> > WIndows, Mac, Solaris and Linux will cover most Firefox developers.\n> > Is git to go on those platforms? Is WIndows native or cygwin?\n>\n> I think the windows stuff may still be cygwin, but Mac and Solaris work\n> fine with the git, of course. It's just simple posix code, after all\n\nIt is going to have to be native Windows to move some of the\ndevelopers over. They are true blue MS types that won't touch anything\nclose to Unix so cygwin is out.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21083","messageId":"20060602041107.GA5429@spearce.org","threadId":"4370","inReplyTo":"9e4733910606012100s7ace4721le6fbfbcaadfb6c43@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-06-02T04:11:07Z","receivedAt":"2006-06-02T04:11:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jon Smirl wrote:\n> On 6/1/06, Keith Packard wrote:\n> >On Thu, 2006-06-01 at 23:47 -0400, Jon Smirl wrote:\n> >> On 6/1/06, Keith Packard wrote:\n> >> > Git runs fine on Windows these days; asking people to use reasonable\n> >> > tools to contribute to the project doesn't seem crazy to me.\n> >>\n> >> WIndows, Mac, Solaris and Linux will cover most Firefox developers.\n> >> Is git to go on those platforms? Is WIndows native or cygwin?\n> >\n> >I think the windows stuff may still be cygwin, but Mac and Solaris work\n> >fine with the git, of course. It's just simple posix code, after all\n> \n> It is going to have to be native Windows to move some of the\n> developers over. They are true blue MS types that won't touch anything\n> close to Unix so cygwin is out.\n\nThen GIT on Windows might be out.\n\nGIT today requires not only a decent UNIX shell but also, GNU tools,\nPerl and Python. Porting to Solaris has recently had some more\neffort put into it to remove some of the GNU tool dependencies but\nperhaps one of the most important features (git-merge-recursive)\nis a Python script.\n\nI'm running GIT at work on a Windows/Cygwin installation which is\nreally quite bare bones. I think I have about 15 Cygwin packages\ninstalled total and GIT is running fine in that environment.\nIt can't send patches by email but the corporate firewalls wouldn't\npermit that anyway...\n\nPerhaps you can tell the true blue MS types that Cygwin is a native\nWindows application. After all it uses the Win32 API. :-)\n\n-- \nShawn.\n"},{"id":"21084","messageId":"46a038f90606012114m5d6d0d66r9ecd3dea0581d7a4@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-06-02T04:14:28Z","receivedAt":"2006-06-02T04:14:28Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Jon,\n\n> Is anyone interested in helping out with this? My knowledge of git and\n> CVS is limited. Mozilla CVS is about 3GB and it is available via\n> rsync. I can post the parsecvs changes if wanted.\n\nFetchin it now, I'll definitely have a play. Have you tried with a\nrecent git-cvsimport? In the last 2 weeks it's seen a lot of\nperformance & scalability improvements as we were importing the\ngentoo-x86 tree.\n\nGrab the latest 'master' branch from Junio and give the import a go.\n\ncheers,\n\n\n\nmartin\n"},{"id":"21085","messageId":"46a038f90606012116t478edacex72a441544f395af4@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606012100s7ace4721le6fbfbcaadfb6c43@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-06-02T04:16:37Z","receivedAt":"2006-06-02T04:16:37Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/2/06, Jon Smirl wrote:\n> It is going to have to be native Windows to move some of the\n> developers over. They are true blue MS types that won't touch anything\n> close to Unix so cygwin is out.\n\nAs others have pointed out, you have git-cvsserver which emulates a\nCVS server on top of GIT, so it can be used with (almost any) CVS\nclient. They will be 2nd class citizens however...\n\ncheers,\n\n\nmartin\n"},{"id":"21086","messageId":"1149223164.2443.33.camel@dv","threadId":"4370","inReplyTo":"20060602041107.GA5429@spearce.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-02T04:39:24Z","receivedAt":"2006-06-02T04:39:24Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2006-06-02 at 00:11 -0400, Shawn Pearce wrote:\n\n> GIT today requires not only a decent UNIX shell but also, GNU tools,\n> Perl and Python. Porting to Solaris has recently had some more\n> effort put into it to remove some of the GNU tool dependencies but\n> perhaps one of the most important features (git-merge-recursive)\n> is a Python script.\n\nThe great thing about git is that it's modular. A single utility can be\nreplaced and retested in the same environment, without having to rewrite\nthe rest of the scripts. A dedicated programmer with good C and Python\nskills could rewrite git-merge-recursive.py in C in 2 days, I believe.\nAdd a few days of bug fixing, of course.\n\nDependency on Cygwin, Perl and Python is too much. Windows is becoming\na legacy system in some circles, and it may run on legacy hardware. Yet\nit's irreplaceable as a testing platform for many projects.\n\nI really need to rewrite git-clean in C, since it doesn't handle\nembedded newlines properly.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21087","messageId":"20060602044404.GB5429@spearce.org","threadId":"4370","inReplyTo":"1149223164.2443.33.camel@dv","subject":"Re: Importing Mozilla CVS into git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-06-02T04:44:04Z","receivedAt":"2006-06-02T04:44:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Pavel Roskin wrote:\n> On Fri, 2006-06-02 at 00:11 -0400, Shawn Pearce wrote:\n> \n> > GIT today requires not only a decent UNIX shell but also, GNU tools,\n> > Perl and Python. Porting to Solaris has recently had some more\n> > effort put into it to remove some of the GNU tool dependencies but\n> > perhaps one of the most important features (git-merge-recursive)\n> > is a Python script.\n> \n> The great thing about git is that it's modular. A single utility can be\n> replaced and retested in the same environment, without having to rewrite\n> the rest of the scripts. A dedicated programmer with good C and Python\n> skills could rewrite git-merge-recursive.py in C in 2 days, I believe.\n> Add a few days of bug fixing, of course.\n\nHeh. Funny you should mention that. I was just thinking a few\nminutes ago about working on that exact change...\n \n> Dependency on Cygwin, Perl and Python is too much. Windows is becoming\n> a legacy system in some circles, and it may run on legacy hardware. Yet\n> it's irreplaceable as a testing platform for many projects.\n\nIts already legacy to me. Heck its 2006 and my work desktop still\nsays something about 2000 when I login. :-)\n \n-- \nShawn.\n"},{"id":"21088","messageId":"9e4733910606012144p5f4fda26sdc2de2cc77b71fe7@mail.gmail.com","threadId":"4370","inReplyTo":"1149223164.2443.33.camel@dv","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-02T04:44:56Z","receivedAt":"2006-06-02T04:44:56Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/2/06, Pavel Roskin wrote:\n> Dependency on Cygwin, Perl and Python is too much. Windows is becoming\n> a legacy system in some circles, and it may run on legacy hardware. Yet\n> it's irreplaceable as a testing platform for many projects.\n\n80% of Mozilla commiters are running Windows. Some are OS bilingual\nbut many are not.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21092","messageId":"7vac8wdpr5.fsf@assigned-by-dhcp.cox.net","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606011809401.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T06:40:30Z","receivedAt":"2006-06-02T06:40:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> You're much better off using \"gitk --all\" if you want to see the result, \n> the \"show-branch\" this is really broken. It is using the old algorithm \n> that we used to use for \"git-rev-tree\", and got rid of about a year ago \n> there in favour of git-rev-list ;)\n\nAre you sure about it? My recollection is it uses the\nmerge-base logic, naturally enhanced for multiple heads.\n\nAnd enhancing it to support more than one int wide bitmap should\nnot be too difficult, although looking at the output would be\nvery taxing for human eye, so I do not know if it is worth it.\n"},{"id":"21093","messageId":"Pine.LNX.4.63.0606020941210.2482@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4370","inReplyTo":"20060602044404.GB5429@spearce.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-02T07:46:29Z","receivedAt":"2006-06-02T07:46:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Jun 2006, Shawn Pearce wrote:\n\n> Pavel Roskin wrote:\n> > On Fri, 2006-06-02 at 00:11 -0400, Shawn Pearce wrote:\n> > \n> > > GIT today requires not only a decent UNIX shell but also, GNU tools,\n> > > Perl and Python. Porting to Solaris has recently had some more\n> > > effort put into it to remove some of the GNU tool dependencies but\n> > > perhaps one of the most important features (git-merge-recursive)\n> > > is a Python script.\n> > \n> > The great thing about git is that it's modular. A single utility can be\n> > replaced and retested in the same environment, without having to rewrite\n> > the rest of the scripts. A dedicated programmer with good C and Python\n> > skills could rewrite git-merge-recursive.py in C in 2 days, I believe.\n> > Add a few days of bug fixing, of course.\n> \n> Heh. Funny you should mention that. I was just thinking a few\n> minutes ago about working on that exact change...\n\nI thought about this a couple of weeks ago. I recalled to have read \nsomething about the principle: if there is more than one merge-base \ncandidate, it starts by merging the merge-base candidates until there is \nonly one 'virtual' merge-base candidate.\n\nHowever, looking at the code I fainted. Sure, a lot should be way easier \nin C, because the functions are already there, _but_ it seemed too much \nwork for one afternoon nevertheless (and I did not have more time to \nspare).\n\nCiao,\nDscho\n"},{"id":"21105","messageId":"Pine.LNX.4.64.0606020849390.5498@g5.osdl.org","threadId":"4370","inReplyTo":"7vac8wdpr5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-02T15:53:40Z","receivedAt":"2006-06-02T15:53:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 1 Jun 2006, Junio C Hamano wrote:\n> > You're much better off using \"gitk --all\" if you want to see the result, \n> > the \"show-branch\" this is really broken. It is using the old algorithm \n> > that we used to use for \"git-rev-tree\", and got rid of about a year ago \n> > there in favour of git-rev-list ;)\n> \n> Are you sure about it? My recollection is it uses the\n> merge-base logic, naturally enhanced for multiple heads.\n\nWell, it's all the same algorithm, where just the bit usage differs. \ngit-rev-tree is slightly closer, if only because the original \ngit-merge-base only did two heads, if I recall correctly (while \ngit-rev-tree did 16 - the ability of git-show-branch to do 29 came from \njust using all the free bits rather than the high bits like rev-tree did)\n\n> And enhancing it to support more than one int wide bitmap should\n> not be too difficult, although looking at the output would be\n> very taxing for human eye, so I do not know if it is worth it.\n\nYeah, I don't think there is any reason to really support it. If you have \nmore than a few heads, you really do need the graphical version to see \nwhat is going on, and git-show-branch doesn't buy you anything.\n\n\t\tLinus\n"},{"id":"21107","messageId":"7vslmnbl92.fsf@assigned-by-dhcp.cox.net","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606020849390.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T16:00:41Z","receivedAt":"2006-06-02T16:00:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Yeah, I don't think there is any reason to really support it. If you have \n> more than a few heads, you really do need the graphical version to see \n> what is going on, and git-show-branch doesn't buy you anything.\n\nThe real reason it uses a bit per given ref is what it wants to\nshow is different from what gitk shows. It wants to show which\nones are reachable from which head on each commit -- in gitk the\nuser has to follow the line to find it out.\n\nHowever, to track 300 branches, you would need a terminal with\n360 columns or so, _and_ you have to count columns to see if a\ngiven commit is reachable from the ref you are interested in, so\nit is not useful at all in practice to do more than a handful\nrefs at a time.\n"},{"id":"21121","messageId":"9e4733910606021709g4156f814md543f51b6a8eb2e8@mail.gmail.com","threadId":"4370","inReplyTo":"1149220518.5521.43.camel@neko.keithp.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-03T00:09:16Z","receivedAt":"2006-06-03T00:09:16Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"If I parsecvs this pair it fails:\n\n/home/jonsmirl/mozilla/mozilla/dom/src/base/nsFocusController.h,v\n/home/jonsmirl/mozilla/mozilla/dom/src/base/nsGlobalWindow.cpp,v\n\n[jonsmirl@jonsmirl foo]$ ../parsecvs master matched by date\nfatal: Not a valid object name (null)\ngit-read-tree '(null)' failed\n[jonsmirl@jonsmirl foo]$\n\nBut parsecvs works on each of them individually.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21125","messageId":"9e4733910606022128h23ff94fbg3fcb4fa191254b5a@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606011755n29a149f2m1409c5a23888f1c5@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-03T04:28:20Z","receivedAt":"2006-06-03T04:28:20Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/1/06, Jon Smirl wrote:\n> With the attached patch you can parse the entire Mozilla tree. The\n> tree has over 100,000 files in it and about 300 branches.\n\nI was a little low with these counts, more like 110,000 files and some\nparts of the tree have 1,000 branches. Total tree size is 3GB.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21172","messageId":"200606040116.38036.robin.rosenberg.lists@dewire.com","threadId":"4370","inReplyTo":"46a038f90606012116t478edacex72a441544f395af4@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Robin Rosenberg (list subscriber)","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-06-03T23:16:37Z","receivedAt":"2006-06-03T23:16:37Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 02 juni 2006 06:16 skrev Martin Langhoff:\n> On 6/2/06, Jon Smirl wrote:\n> > It is going to have to be native Windows to move some of the\n> > developers over. They are true blue MS types that won't touch anything\n> > close to Unix so cygwin is out.\nThat could be fixed with nice packaging since many CVS users in Windows\nnever use a command line anyway since TortoiseCVS is so nice. \n\n> As others have pointed out, you have git-cvsserver which emulates a\n> CVS server on top of GIT, so it can be used with (almost any) CVS\n> client. They will be 2nd class citizens however...\n\n(Yet) Another problem is that many windows tools use CR LF as the line ending.\nAlmost all windows editors default to CRLF and some detect existing line \nendings. No editing with notepad anymore. Of course that is a problem \nregardless of whether a git or cvs client is used. You'll get these big \neverything-changed commits that alter between CRLF and LF.\n\n-- robin\n"},{"id":"21173","messageId":"Pine.LNX.4.64.0606031631480.5498@g5.osdl.org","threadId":"4370","inReplyTo":"200606040116.38036.robin.rosenberg.lists@dewire.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-03T23:47:36Z","receivedAt":"2006-06-03T23:47:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n> \n> (Yet) Another problem is that many windows tools use CR LF as the line ending.\n> Almost all windows editors default to CRLF and some detect existing line \n> endings. No editing with notepad anymore. Of course that is a problem \n> regardless of whether a git or cvs client is used. You'll get these big \n> everything-changed commits that alter between CRLF and LF.\n\nThe only sane approach there (if you want to be at all cross-platform) is \nto just force everybody to _commit_ in UNIX '\\n'-only format. Especially \nas most Windows tools probably handle that fine on reading (just have \ntrouble writing them).\n\nAnd that shouldn't actually be that hard to do. The most trivial approach \nis to have just a pre-trigger on commits, but let's face it, that would \nnot be a good \"full\" solution. A better one is to just make the whole\n\"git update-index\" thing just have a \"automatically ignore CR/LF\" mode.\n\nWhich really shouldn't be that hard. I think it's literally a matter of \nteaching \"index_fd()\" in sha1_file.c to recognize text-files, and remove \nCR/LF from them. All done (except to add the flag that enables the \ndetection, of course - just so that sane systems won't have the overhead \nor the \"corrupt binary files\" issue).\n\nSomething like this is TOTALLY UNTESTED!\n\n(You also need to teach \"diff\" to ignore differences in cr/lf, and this \npatch is bad because it's unconditional, and probably doesn't work \nanyway, but hey, the idea is possibly sound. Maybe)\n\n\t\tLinus\n---\ndiff --git a/sha1_file.c b/sha1_file.c\nindex aea0f40..6dc6a3f 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1740,9 +1740,30 @@ int index_pipe(unsigned char *sha1, int \n \treturn ret;\n }\n \n+static unsigned long autodetect_crlf(unsigned char *src, unsigned long size)\n+{\n+\tunsigned long newsize = 0;\n+\tunsigned char *dst = src;\n+\tunsigned char last = 0;\n+\n+\twhile (size) {\n+\t\tunsigned char c = *src++;\n+\t\tif (last == '\\r' && c == '\\n') {\n+\t\t\tdst[-1] = '\\n';\n+\t\t} else {\n+\t\t\tnewsize++;\n+\t\t\tdst++;\n+\t\t\tif (dst != src)\n+\t\t\t\tdst[-1] = c;\n+\t\t}\n+\t\tlast = c;\n+\t}\n+\treturn newsize;\n+}\n+\n int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)\n {\n-\tunsigned long size = st->st_size;\n+\tunsigned long size = st->st_size, use_size;\n \tvoid *buf;\n \tint ret;\n \tunsigned char hdr[50];\n@@ -1755,12 +1776,15 @@ int index_fd(unsigned char *sha1, int fd\n \tif (buf == MAP_FAILED)\n \t\treturn -1;\n \n-\tif (!type)\n+\tuse_size = size;\n+\tif (!type) {\n \t\ttype = blob_type;\n+\t\tuse_size = autodetect_crlf(buf, size);\n+\t}\n \tif (write_object)\n-\t\tret = write_sha1_file(buf, size, type, sha1);\n+\t\tret = write_sha1_file(buf, use_size, type, sha1);\n \telse {\n-\t\twrite_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);\n+\t\twrite_sha1_file_prepare(buf, use_size, type, sha1, hdr, &hdrlen);\n \t\tret = 0;\n \t}\n \tif (size)\n"},{"id":"21183","messageId":"4fb292fa0606031924v42024765l9f068f6915bfcf96@mail.gmail.com","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606031631480.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Bertrand Jacquin","fromEmail":"beber.mailing@gmail.com","sentAt":"2006-06-04T02:24:45Z","receivedAt":"2006-06-04T02:24:45Z","isPatch":false,"sender":{"key":"beber.mailing@gmail.com","avatar":null},"body":"On 6/4/06, Linus Torvalds wrote:\n>\n>\n> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n> >\n> > (Yet) Another problem is that many windows tools use CR LF as the line ending.\n> > Almost all windows editors default to CRLF and some detect existing line\n> > endings. No editing with notepad anymore. Of course that is a problem\n> > regardless of whether a git or cvs client is used. You'll get these big\n> > everything-changed commits that alter between CRLF and LF.\n>\n> The only sane approach there (if you want to be at all cross-platform) is\n> to just force everybody to _commit_ in UNIX '\\n'-only format. Especially\n> as most Windows tools probably handle that fine on reading (just have\n> trouble writing them).\n>\n> And that shouldn't actually be that hard to do. The most trivial approach\n> is to have just a pre-trigger on commits, but let's face it, that would\n> not be a good \"full\" solution. A better one is to just make the whole\n> \"git update-index\" thing just have a \"automatically ignore CR/LF\" mode.\n>\n> Which really shouldn't be that hard. I think it's literally a matter of\n> teaching \"index_fd()\" in sha1_file.c to recognize text-files, and remove\n> CR/LF from them. All done (except to add the flag that enables the\n> detection, of course - just so that sane systems won't have the overhead\n> or the \"corrupt binary files\" issue).\n>\n> Something like this is TOTALLY UNTESTED!\n>\n> (You also need to teach \"diff\" to ignore differences in cr/lf, and this\n> patch is bad because it's unconditional, and probably doesn't work\n> anyway, but hey, the idea is possibly sound. Maybe)\n\nIs it also apply for binary files ? It could corrupt files as well.\nIf end-user application don't understand '\\n' but '\\r\\n', you can have\nbad issues (I think to notepad here (yes crappy, but ..)). Couldn't it\nbe configurable ?\n\n-- \n# Beber : beber@gna.org\n# IM : beber@jabber.fr\n# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}\n"},{"id":"21189","messageId":"e5u0o0$3rm$1@sea.gmane.org","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606031631480.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-04T07:05:36Z","receivedAt":"2006-06-04T07:05:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 4 Jun 2006, Linus Torvalds wrote:\n\n> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n>> \n>> (Yet) Another problem is that many windows tools use CR LF as the line ending.\n>> Almost all windows editors default to CRLF and some detect existing line \n>> endings. No editing with notepad anymore. Of course that is a problem \n>> regardless of whether a git or cvs client is used. You'll get these big \n>> everything-changed commits that alter between CRLF and LF.\n> \n> The only sane approach there (if you want to be at all cross-platform) is \n> to just force everybody to _commit_ in UNIX '\\n'-only format. Especially \n> as most Windows tools probably handle that fine on reading (just have \n> trouble writing them).\n> \n> And that shouldn't actually be that hard to do. The most trivial approach \n> is to have just a pre-trigger on commits, but let's face it, that would \n> not be a good \"full\" solution. A better one is to just make the whole\n> \"git update-index\" thing just have a \"automatically ignore CR/LF\" mode.\n\nWhy wouldn't it be good solution?\n\nBTW. wouldn't Mercurial encode/decode filters\n\n http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter\n\nbe a better solution than modifying files by \"git update-index\", \nwith all problems it can cause (not detected binary files, text files\nwhich have to be in CR/LF line ending,...).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"21212","messageId":"Pine.LNX.4.64.0606041050010.5498@g5.osdl.org","threadId":"4370","inReplyTo":"e5u0o0$3rm$1@sea.gmane.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-04T17:55:46Z","receivedAt":"2006-06-04T17:55:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Jun 2006, Jakub Narebski wrote:\n> > \n> > And that shouldn't actually be that hard to do. The most trivial approach \n> > is to have just a pre-trigger on commits, but let's face it, that would \n> > not be a good \"full\" solution. A better one is to just make the whole\n> > \"git update-index\" thing just have a \"automatically ignore CR/LF\" mode.\n> \n> Why wouldn't it be good solution?\n\nThe pre-commit filter thing should work fine, and hey, maybe it's worth \ndoing that way. I just worry/think that it will result in tons of noise \nwhen you do a \"git diff\" and \"git update-index --refresh\" on a file that \nhas been changed, but then the change reverted.\n\nBut I didn't really think it through very deeply, it was just an idle \"I \nthink the pre-commit hook will fall down when X happens that is a \nnon-commit event\" thought. I suspect this is one of those things where \nsomebody actually working in that kind of environment will figure out what \nthe problems are, and what the righ solution is.\n\n> BTW. wouldn't Mercurial encode/decode filters\n> \n> http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter\n> \n> be a better solution than modifying files by \"git update-index\", \n> with all problems it can cause (not detected binary files, text files\n> which have to be in CR/LF line ending,...).\n\nPlease do realize that the patch I sent out was absolutely _not_ meant to \nbe taken seriously. It was more a \"somebody could try this in a windows \nenvironment, and if it works as an approach, we can try to do it right\".\n\nI'm absolutely _not_ suggesting merging that patch as-is or even in any \nform very close to it. It clearly needs a config file entry with filename \npatterns etc at a minimum.\n\n\t\tLinus\n"},{"id":"21220","messageId":"200606042144.45385.robin.rosenberg.lists@dewire.com","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606041050010.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Robin Rosenberg (list subscriber)","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-06-04T19:44:45Z","receivedAt":"2006-06-04T19:44:45Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 04 juni 2006 19:55 skrev Linus Torvalds:\n> On Sun, 4 Jun 2006, Jakub Narebski wrote:\n> > > And that shouldn't actually be that hard to do. The most trivial\n> > > approach is to have just a pre-trigger on commits, but let's face it,\n> > > that would not be a good \"full\" solution. A better one is to just make\n> > > the whole \"git update-index\" thing just have a \"automatically ignore\n> > > CR/LF\" mode.\n> >\n> > Why wouldn't it be good solution?\n>\n> The pre-commit filter thing should work fine, and hey, maybe it's worth\n> doing that way. I just worry/think that it will result in tons of noise\n> when you do a \"git diff\" and \"git update-index --refresh\" on a file that\n> has been changed, but then the change reverted.\n>\n> But I didn't really think it through very deeply, it was just an idle \"I\n> think the pre-commit hook will fall down when X happens that is a\n> non-commit event\" thought. I suspect this is one of those things where\n> somebody actually working in that kind of environment will figure out what\n> the problems are, and what the righ solution is.\n>\n> > BTW. wouldn't Mercurial encode/decode filters\n> >\n> > http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter\n> >\n> > be a better solution than modifying files by \"git update-index\",\n> > with all problems it can cause (not detected binary files, text files\n> > which have to be in CR/LF line ending,...).\n>\n> Please do realize that the patch I sent out was absolutely _not_ meant to\n> be taken seriously. It was more a \"somebody could try this in a windows\n> environment, and if it works as an approach, we can try to do it right\".\n\nOther version control systems simply treat text and binary files differently. \nNo smart(ass) logic doing the wrong thing. A text file gets processed on\ncheck-in AND checkout depending on it's type and the client setting.\nSome heuristics may be applied when adding files. i.e look-up according to \nmagic cookies or looking for bytes that simply do not occur in text files \n(e..g a nul byte). Those few systems that I know about treat the type as a \nfile (as opposed to a version specific) attribute. Some systems have lots of \nfile types, not just text and binary. Encoding is about the only thing that \nwould interest me, although not terribly important (except the file name), \nbut that may be off topic for this thread.\n\nThe hash-on-the whole-tree might be a reason for making the attribute \nversion-specific.\n\nMercurial's filters sounds like a good way to implement file types in a \ngeneric way as long as git's excellent performance isn't hurt.\n\n> I'm absolutely _not_ suggesting merging that patch as-is or even in any\n> form very close to it. It clearly needs a config file entry with filename\n> patterns etc at a minimum.\n\nDo people apply your patches right away, like it's some god-like commandments?\n\n-- robin\n"},{"id":"21221","messageId":"Pine.LNX.4.64.0606041256480.5498@g5.osdl.org","threadId":"4370","inReplyTo":"200606042144.45385.robin.rosenberg.lists@dewire.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-04T20:00:15Z","receivedAt":"2006-06-04T20:00:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n> \n> Other version control systems simply treat text and binary files differently. \n> No smart(ass) logic doing the wrong thing.\n\nTreating text and binary file differently _is_ the \"smart(ass) logic doing \nthe wrong thing\".\n\nGit really shouldn't do that. The patch was meant to show how you really \ndon't need to - the internal objects would never be \"binary vs text\", \nthere would be a way to just basically map one onto another.\n\n> > I'm absolutely _not_ suggesting merging that patch as-is or even in any\n> > form very close to it. It clearly needs a config file entry with filename\n> > patterns etc at a minimum.\n> \n> Do people apply your patches right away, like it's some god-like commandments?\n\nWhat's your problem here, exactly? \n\nI was just trying to point out that my patch was an example, where \nsomebody who cares (not me) can use it as a starting point.\n\nIf you can't be civil, at least be quiet, ok?\n\n\t\tLinus\n"},{"id":"21227","messageId":"200606042325.58884.robin.rosenberg.lists@dewire.com","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606041256480.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Robin Rosenberg (list subscriber)","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-06-04T21:25:58Z","receivedAt":"2006-06-04T21:25:58Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 04 juni 2006 22:00 skrev Linus Torvalds:\n> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n> > Other version control systems simply treat text and binary files\n> > differently. No smart(ass) logic doing the wrong thing.\n>\n> Treating text and binary file differently _is_ the \"smart(ass) logic doing\n> the wrong thing\".\n>\n> Git really shouldn't do that. The patch was meant to show how you really\n> don't need to - the internal objects would never be \"binary vs text\",\n> there would be a way to just basically map one onto another.\n\nYour patch assumes all files are text and the transformation doesn't corrupt \nthe file, which isn't true. CR-LF combinations cannot be translated to LF and\nvice verse in all files, simply becuase what looks like CR LF isn't two \ncharacters, but something else. Looking for a nul byte and possibly some\nother magic byte would make you right more often, but not always.\n\n[...]\n> If you can't be civil, at least be quiet, ok?\n>\n> \t\tLinus\nA bad joke, I'm sorry. It wasn't ment to be offensive.\n\n-- robin\n"},{"id":"21228","messageId":"200606050002.55818.robin.rosenberg.lists@dewire.com","threadId":"4370","inReplyTo":"200606042325.58884.robin.rosenberg.lists@dewire.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Robin Rosenberg (list subscriber)","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-06-04T22:02:55Z","receivedAt":"2006-06-04T22:02:55Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Just forget this post... @_@ (except the last line)\n\nsöndag 04 juni 2006 23:25 skrev Robin Rosenberg (list subscriber):\n> söndag 04 juni 2006 22:00 skrev Linus Torvalds:\n> > On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n> > > Other version control systems simply treat text and binary files\n> > > differently. No smart(ass) logic doing the wrong thing.\n> >\n> > Treating text and binary file differently _is_ the \"smart(ass) logic\n> > doing the wrong thing\".\n> >\n> > Git really shouldn't do that. The patch was meant to show how you really\n> > don't need to - the internal objects would never be \"binary vs text\",\n> > there would be a way to just basically map one onto another.\n>\n> Your patch assumes all files are text and the transformation doesn't\n> corrupt the file, which isn't true. CR-LF combinations cannot be translated\n> to LF and vice verse in all files, simply becuase what looks like CR LF\n> isn't two characters, but something else. Looking for a nul byte and\n> possibly some other magic byte would make you right more often, but not\n> always.\n>\n> [...]\n>\n> > If you can't be civil, at least be quiet, ok?\n> >\n> > \t\tLinus\n>\n> A bad joke, I'm sorry. It wasn't ment to be offensive.\n>\n"},{"id":"21235","messageId":"Pine.LNX.4.64.0606041615430.5498@g5.osdl.org","threadId":"4370","inReplyTo":"200606042325.58884.robin.rosenberg.lists@dewire.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-04T23:19:14Z","receivedAt":"2006-06-04T23:19:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:\n>\n> Your patch assumes all files are text and the transformation doesn't corrupt \n> the file, which isn't true.\n\nHow do you think things get done? You test the _technology_ first, and \nthen if that is shown to be workable in a real environment, _then_ do you \nactually add the polish to make it useful.\n\nThat was all the patch was. A technology demonstration. I'd really like to \nhear whether it works in a simple CR/LF environment, because if it \ndoesn't, then it needs some totally different approach.\n\nAnd yes, I could test it myself, but (a) I'm way too lazy and (b) I \nconsciously try to get others involved because it's a better long-term \nstrategy (because I expect to be ay too lazy in the future too)\n\n\t\tLinus\n"},{"id":"21240","messageId":"f36b08ee0606041710r695924cdgaea7822d987ebe94@mail.gmail.com","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606031631480.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2006-06-05T00:10:46Z","receivedAt":"2006-06-05T00:10:46Z","isPatch":false,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"On 6/4/06, Linus Torvalds wrote:\n+static unsigned long autodetect_crlf(unsigned char *src, unsigned long size)\n> +{\n> + unsigned long newsize = 0;\n> + unsigned char *dst = src;\n> + unsigned char last = 0;\n> +\n> + while (size) {\n> + unsigned char c = *src++;\n\nsize--;\nis missing\n\n> + if (last == '\\r' && c == '\\n') {\n> + dst[-1] = '\\n';\n> + } else {\n> + newsize++;\n> + dst++;\n> + if (dst != src)\n> + dst[-1] = c;\n> + }\n> + last = c;\n> + }\n> + return newsize;\n> +}\n\nYakov\n"},{"id":"21304","messageId":"46a038f90606052255s62cda81bt62d7442beb26658a@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606022128h23ff94fbg3fcb4fa191254b5a@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-06-06T05:55:08Z","receivedAt":"2006-06-06T05:55:08Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/3/06, Jon Smirl wrote:\n> On 6/1/06, Jon Smirl wrote:\n> > With the attached patch you can parse the entire Mozilla tree. The\n> > tree has over 100,000 files in it and about 300 branches.\n>\n> I was a little low with these counts, more like 110,000 files and some\n> parts of the tree have 1,000 branches. Total tree size is 3GB.\n\nI don't think it really has that many branches. If I am to believe\ncvsps (which took 3GB to walk the history), it has some branches with\nrecursive loops in their ancestry (MANG_MATH_BRANCH and\nSpiderMonkey140_BRANCH have eachother as ancestors!?), 197969 commits\nand 796 branches.\n\nThis repository has been mangled quite badly. Don't know what you guys\ndid with it, but it sure isn't pretty. I'm working on getting\ngit-cvsimport to get through a complete import.\n\ncheers,\n\n\n\nmartin\n"},{"id":"21320","messageId":"9e4733910606060813r41037467u74235f7a9386c1e0@mail.gmail.com","threadId":"4370","inReplyTo":"46a038f90606052255s62cda81bt62d7442beb26658a@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-06T15:13:34Z","receivedAt":"2006-06-06T15:13:34Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/6/06, Martin Langhoff wrote:\n> On 6/3/06, Jon Smirl wrote:\n> > On 6/1/06, Jon Smirl wrote:\n> > > With the attached patch you can parse the entire Mozilla tree. The\n> > > tree has over 100,000 files in it and about 300 branches.\n> >\n> > I was a little low with these counts, more like 110,000 files and some\n> > parts of the tree have 1,000 branches. Total tree size is 3GB.\n>\n> I don't think it really has that many branches. If I am to believe\n> cvsps (which took 3GB to walk the history), it has some branches with\n> recursive loops in their ancestry (MANG_MATH_BRANCH and\n> SpiderMonkey140_BRANCH have eachother as ancestors!?), 197969 commits\n> and 796 branches.\n\nIt probably is 796 and not a 1,000. The branch names were scrolling\nacross my screen and I just estimated.\n\n> This repository has been mangled quite badly. Don't know what you guys\n> did with it, but it sure isn't pretty. I'm working on getting\n> git-cvsimport to get through a complete import.\n\nThe repository is close to 10 years old and it has gone through a\nnumber of corporate reorgs. Who knows what has happened to it over\nthat length of time.\n\nHave you looked at the SVN CVS import tool? It imported Mozilla on the\nfirst try. If you download the source they have built about 40 test\nrepositories with various errors. Those would make a good test suite\nfor cvsps. http://cvs2svn.tigris.org\n\nI have been working on converting the svn tool to do git commands but\nmy git knowledge is limited so it has been slow going. The last stage,\npass 8, is very similar to what the git tools do. The svn commands\njust need to be swapped for git ones.\n\nIf you get git-cvsimport working I'll use it instead. Will the cvsps\nprocess stay small enough to run on a 32b machine? The svn tools are\nvery RAM efficient since they use an external db. Can cvsps read from\na local copy of the repository without using a CVS server?\n\nWe are going to have to develop some kind of incremental mechanism for\nupdating the new git tree. It can take up to two days to convert the\nrepository, Mozilla development can't be shut down that long for a\ntransition. Git will also need to mirror the CVS repository (check-in\nstill going to CVS) for a long time while we convince everyone on the\nmerits of switching.\n\nMy imported svn version of Mozilla has a lot of performance problems.\nOne of the directories has over 200,000 files in it slowing downing\nthe filesystem. The repository went from 3GB CVS to 8GB svn, probably\ndue to svn using 1000s of tiny files. I'll look around and see if svn\nhas a pack feature like git.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21339","messageId":"46a038f90606061257v569aefackc4920a20f2970b0f@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606060813r41037467u74235f7a9386c1e0@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-06-06T19:57:22Z","receivedAt":"2006-06-06T19:57:22Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/7/06, Jon Smirl wrote:\n> Have you looked at the SVN CVS import tool? It imported Mozilla on the\n> first try. If you download the source they have built about 40 test\n> repositories with various errors. Those would make a good test suite\n> for cvsps. http://cvs2svn.tigris.org\n\nHaven't yet, but I'll do. I'm currently quite busy at work, but I'm\nrunning these imports (Moz, Gentoo) and trying to address issues\narising. Will look into SVN's tool it when I have a bit more time.\n\nWhat I'll probably do is steal those test cases! ;-)\n\n> I have been working on converting the svn tool to do git commands but\n> my git knowledge is limited so it has been slow going. The last stage,\n> pass 8, is very similar to what the git tools do. The svn commands\n> just need to be swapped for git ones.\n\nThat would be interesting. And yet, I would have to evaluate how to\ntransition gateways running git-cvsimport incrementally to a different\nimporter.\n\nDoes it do incremental imports?\n\n> If you get git-cvsimport working I'll use it instead. Will the cvsps\n> process stay small enough to run on a 32b machine? The svn tools are\n\nCurrently not, but I do hope that the moz team has access to at least\none machine with more than 32MB ;-)\n\nWith the current code, you will want a 3GB machine to run the git-cvsimport\n\ngit-cvsimport has a memory leak that I've been chasing for a while and\nI'll eventually fix, so it should fit in 32MB comfortably. cvsps is\nmemory bound, and will probably take quite a bit of work to fix that.\nHowever, I suspect we can make it a lot more efficient.\n\n> very RAM efficient since they use an external db. Can cvsps read from\n> a local copy of the repository without using a CVS server?\n\n> We are going to have to develop some kind of incremental mechanism for\n> updating the new git tree. It can take up to two days to convert the\n> repository, Mozilla development can't be shut down that long for a\n\nYou don't have to. Run an initial import, and then freeze development\nand run an incremental -- which will take an hour at the most. And\nthen your mozilla.git repo is ready and up to date.\n\n> transition. Git will also need to mirror the CVS repository (check-in\n> still going to CVS) for a long time while we convince everyone on the\n> merits of switching.\n\nThat's easy -- run git-cvsimport on a cronjob.\n\n> My imported svn version of Mozilla has a lot of performance problems.\n> One of the directories has over 200,000 files in it slowing downing\n> the filesystem. The repository went from 3GB CVS to 8GB svn, probably\n> due to svn using 1000s of tiny files. I'll look around and see if svn\n> has a pack feature like git.\n\nAt least they got a good importer ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"21359","messageId":"1149639142.28173.37.camel@neko.keithp.com","threadId":"4370","inReplyTo":"46a038f90606061257v569aefackc4920a20f2970b0f@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-07T00:12:22Z","receivedAt":"2006-06-07T00:12:22Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Wed, 2006-06-07 at 07:57 +1200, Martin Langhoff wrote:\n\n> git-cvsimport has a memory leak that I've been chasing for a while and\n> I'll eventually fix, so it should fit in 32MB comfortably. cvsps is\n> memory bound, and will probably take quite a bit of work to fix that.\n> However, I suspect we can make it a lot more efficient.\n\nYeah, parsecvs is a memory pig as well -- it builds a giant in-memory\nrepresentation of the entire project history using flat lists of files\nfor every revision, just like git used to do. Fixing that should make it\nrun in small amounts of memory; it only needs 40 bytes per file revision\nfor the raw data as it converts the cvs files to git objects as it reads\nthem, saving only the hash value in memory.\n\nNot relying on cvsps has been a huge feature though; cvsps loses a\ntremendous amount of data, along with making several gross and difficult\nto fix errors in project history from several of my repositories.\n\n-- \nkeith.packard@intel.com\n"},{"id":"21364","messageId":"9e4733910606061740v797886baif6b1edd969dfab2a@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606060813r41037467u74235f7a9386c1e0@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-07T00:40:50Z","receivedAt":"2006-06-07T00:40:50Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/6/06, Jon Smirl wrote:\n> On 6/6/06, Martin Langhoff wrote:\n> > On 6/3/06, Jon Smirl wrote:\n> > > On 6/1/06, Jon Smirl wrote:\n> > > > With the attached patch you can parse the entire Mozilla tree. The\n> > > > tree has over 100,000 files in it and about 300 branches.\n> > >\n> > > I was a little low with these counts, more like 110,000 files and some\n> > > parts of the tree have 1,000 branches. Total tree size is 3GB.\n> >\n> > I don't think it really has that many branches. If I am to believe\n> > cvsps (which took 3GB to walk the history), it has some branches with\n> > recursive loops in their ancestry (MANG_MATH_BRANCH and\n> > SpiderMonkey140_BRANCH have eachother as ancestors!?), 197969 commits\n> > and 796 branches.\n\nMy full import to svn just finished after a day and a half.\nHere are the stats:\n\ncvs2svn Statistics:\n------------------\nTotal CVS Files: 99851\nTotal CVS Revisions: 948580\nTotal Unique Tags: 1505\nTotal Unique Branches: 1577\nCVS Repos Size in KB: 2725843\nTotal SVN Commits: 205787\nFirst Revision Date: Fri Mar 27 21:13:08 1998\nLast Revision Date: Tue May 30 19:28:10 2006\n------------------\nTimings:\n------------------\npass 1: 3602 seconds\npass 2: 227 seconds\npass 3: 66 seconds\npass 4: 1070 seconds\npass 8:124650 seconds\ntotal: 124650 seconds\n[jonsmirl@jonsmirl ~]$\n\n[jonsmirl@jonsmirl svn]$ du -h\n4.0K ./svntest/dav\n12K ./svntest/locks\n40K ./svntest/hooks\n16K ./svntest/conf\n7.4G ./svntest/db/revs\n808M ./svntest/db/revprops\n4.0K ./svntest/db/transactions\n8.2G ./svntest/db\n8.2G ./svntest\n8.2G .\n\n[jonsmirl@jonsmirl svn]$ find | wc\n 411607 411607 10891057\n\nThere are two directories that each contain about 205k files. 205K\nfiles in a single directory is causing svn problems on Ext3.\n\nBottom line, cvs2svn import tool works quite well. Highest memory\nconsumption I saw was 100MB and it used 6GB of extra disk while\nrunning plus space need by svn.\n\nI don't know quite enough about git yet to replace the svn commands it\nuses with git equivalents but if that were done I think most of the\ncvs import problems would be solved. Obviously the svn team has put a\ngreat deal of work into this program.\n\nI don't think replacing the svn commands is very hard, I just haven't\nfigured out the right way to build branches with low-level git yet and\nI don't know Python. I'll bet someone already familiar with git and\ncvs import could convert it in a couple of hours.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21375","messageId":"df0b33100606070202w581ff581i435056f0fbc197f8@mail.gmail.com","threadId":"4370","inReplyTo":"9e4733910606012144p5f4fda26sdc2de2cc77b71fe7@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Igor Bukanov","fromEmail":"igor.bukanov@gmail.com","sentAt":"2006-06-07T09:02:55Z","receivedAt":"2006-06-07T09:02:55Z","isPatch":false,"sender":{"key":"igor.bukanov@gmail.com","avatar":null},"body":"On 6/2/06, Jon Smirl wrote:\n> On 6/2/06, Pavel Roskin wrote:\n> > Dependency on Cygwin, Perl and Python is too much. Windows is becoming\n> > a legacy system in some circles, and it may run on legacy hardware. Yet\n> > it's irreplaceable as a testing platform for many projects.\n>\n> 80% of Mozilla commiters are running Windows. Some are OS bilingual\n> but many are not.\n\nMozilla build system on Windows requires Cygwin and there are 198 Perl\nfiles in Firefox tree. So it is only Python that can be problematic.\n\nRegards, Igor\n"},{"id":"21378","messageId":"1149693688.3415.6.camel@dv","threadId":"4370","inReplyTo":"df0b33100606070202w581ff581i435056f0fbc197f8@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-07T15:21:28Z","receivedAt":"2006-06-07T15:21:28Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Wed, 2006-06-07 at 11:02 +0200, Igor Bukanov wrote:\n> On 6/2/06, Jon Smirl wrote:\n> > On 6/2/06, Pavel Roskin wrote:\n> > > Dependency on Cygwin, Perl and Python is too much. Windows is becoming\n> > > a legacy system in some circles, and it may run on legacy hardware. Yet\n> > > it's irreplaceable as a testing platform for many projects.\n> >\n> > 80% of Mozilla commiters are running Windows. Some are OS bilingual\n> > but many are not.\n> \n> Mozilla build system on Windows requires Cygwin and there are 198 Perl\n> files in Firefox tree. So it is only Python that can be problematic.\n\nThen maybe the existing 3 python files in git (I'm not counting\ncompat/subprocess.py) could be converted to Perl? Perl would be great\nas the \"common denominator\" for interpreted languages.\n\nSearch for \"python to perl\" translator lead me to Perthon:\nhttp://perthon.sourceforge.net/\n\nBut Perthon needs work. My attempt to run it on git-p4import.py failed:\n\n$ perl -I `pwd`/lib perthon.pl git-p4import.py \nCan't coerce array into hash at lib/Perthon/PerthonImpl.pm line 15420.\n\nIt may be a fun project for somebody who wants to learn Perl and Python.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21379","messageId":"9e4733910606070830g24a08771i1a332552a95283d1@mail.gmail.com","threadId":"4370","inReplyTo":"df0b33100606070202w581ff581i435056f0fbc197f8@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-07T15:30:40Z","receivedAt":"2006-06-07T15:30:40Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/7/06, Igor Bukanov wrote:\n> On 6/2/06, Jon Smirl wrote:\n> > On 6/2/06, Pavel Roskin wrote:\n> > > Dependency on Cygwin, Perl and Python is too much. Windows is becoming\n> > > a legacy system in some circles, and it may run on legacy hardware. Yet\n> > > it's irreplaceable as a testing platform for many projects.\n> >\n> > 80% of Mozilla commiters are running Windows. Some are OS bilingual\n> > but many are not.\n>\n> Mozilla build system on Windows requires Cygwin and there are 198 Perl\n> files in Firefox tree. So it is only Python that can be problematic.\n\nOther people have sent me mail saying this may not be as big as\nproblem as was thought, only documentation people on WIndows may be an\nissues.\n\n\n>\n> Regards, Igor\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21381","messageId":"e66t2v$6hb$1@sea.gmane.org","threadId":"4370","inReplyTo":"9e4733910606070830g24a08771i1a332552a95283d1@mail.gmail.com","subject":"Re: Importing Mozilla CVS into git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-07T15:58:37Z","receivedAt":"2006-06-07T15:58:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> On 6/7/06, Igor Bukanov wrote:\n>> On 6/2/06, Jon Smirl wrote:\n>>> On 6/2/06, Pavel Roskin wrote:\n>>>> Dependency on Cygwin, Perl and Python is too much. Windows is becoming\n>>>> a legacy system in some circles, and it may run on legacy hardware. Yet\n>>>> it's irreplaceable as a testing platform for many projects.\n>>>\n>>> 80% of Mozilla commiters are running Windows. Some are OS bilingual\n>>> but many are not.\n>>\n>> Mozilla build system on Windows requires Cygwin and there are 198 Perl\n>> files in Firefox tree. So it is only Python that can be problematic.\n> \n> Other people have sent me mail saying this may not be as big as\n> problem as was thought, only documentation people on WIndows may be an\n> issues.\n\nWith 1.4.0 there should be tar files of documentation. For now, one can use\nhtml and man branches of git.git repository: see the INSTALL file and/or\n\n http://git.or.cz/gitwiki/GitDocumentation\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"21382","messageId":"Pine.LNX.4.64.0606070915220.5498@g5.osdl.org","threadId":"4370","inReplyTo":"e66t2v$6hb$1@sea.gmane.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-07T16:17:28Z","receivedAt":"2006-06-07T16:17:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 7 Jun 2006, Jakub Narebski wrote:\n> > Other people have sent me mail saying this may not be as big as\n> > problem as was thought, only documentation people on WIndows may be an\n> > issues.\n> \n> With 1.4.0 there should be tar files of documentation. For now, one can use\n> html and man branches of git.git repository: see the INSTALL file and/or\n\nI think you misunderstood.\n\nMy guess is that it's the _mozilla_ documentation people that don't \nnecessarily have cygwin and perl, because they don't work with the normal \nbuild.\n\nIe there are people who can write user documentation, without them having \nany clue - or caring about - build systems.\n\n\t\t\tLinus\n"},{"id":"21388","messageId":"46a038f90606071129g2af6e5e2m7a4b979371d9e5db@mail.gmail.com","threadId":"4370","inReplyTo":"Pine.LNX.4.64.0606070915220.5498@g5.osdl.org","subject":"Re: Importing Mozilla CVS into git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-06-07T18:29:20Z","receivedAt":"2006-06-07T18:29:20Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/8/06, Linus Torvalds wrote:\n> My guess is that it's the _mozilla_ documentation people that don't\n> necessarily have cygwin and perl, because they don't work with the normal\n> build.\n>\n> Ie there are people who can write user documentation, without them having\n> any clue - or caring about - build systems.\n\nWhich means that git-cvsserver can probably help them -- I don't think\ndocumentation people (and translators, graphic artists, etc) need all\nthe git smarts. A simplistic TortoiseCVS + git-cvsserver should fit\ntheir usage...\n\ncheers,\n\n\nmartin\n"}]}