{"thread":{"id":"20263","subject":"From P4 to Git","startedAt":"2009-07-28T20:14:34Z","lastAt":"2009-08-04T12:35:08Z","messageCount":16,"participants":["Arnaud Bailly","david@lang.hm","Jakub Narebski","Alex Riesen","Sam Vilain","John Tapsell","Peter Baumann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118981","messageId":"85ljm84lat.fsf@oqube.com","threadId":"20263","inReplyTo":null,"subject":"From P4 to Git","fromName":"Arnaud Bailly","fromEmail":"abailly@oqube.com","sentAt":"2009-07-28T20:14:34Z","receivedAt":"2009-07-28T20:14:34Z","isPatch":false,"sender":{"key":"abailly@oqube.com","avatar":null},"body":"Hello,\nI am investigating the use of Git in a setting where we:\n 1. branches a lot\n 2. have a very large codebase\n\nGiven Git is developed to handle these 2 issues, I suspect it would be a\nvery good choice, but I need to gather some experiments feedback and\nhard figures on how Git performs (storage use, necessary\nbandwidth/resources, maintainance of repositories, cleanup & gc...).\n\nFor the experiment part, I am started working on it but would be\ninterested in other people's experiences.\n\nFor the figures part, I think I read somewhere there exists some\nstatistics on Git usage for Linux kernel. Is this correct ? If true,\nwhere could I find them ? \n\nThanks in advance for answering my (maybe pointless) questions and for\nproducing such a nice piece of software.\n-- \nArnaud Bailly\n"},{"id":"118982","messageId":"alpine.DEB.1.10.0907281331270.28013@asgard.lang.hm","threadId":"20263","inReplyTo":"85ljm84lat.fsf@oqube.com","subject":"Re: From P4 to Git","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-07-28T20:32:27Z","receivedAt":"2009-07-28T20:32:27Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 28 Jul 2009, Arnaud Bailly wrote:\n\n> Hello,\n> I am investigating the use of Git in a setting where we:\n> 1. branches a lot\n> 2. have a very large codebase\n>\n> Given Git is developed to handle these 2 issues, I suspect it would be a\n> very good choice, but I need to gather some experiments feedback and\n> hard figures on how Git performs (storage use, necessary\n> bandwidth/resources, maintainance of repositories, cleanup & gc...).\n>\n> For the experiment part, I am started working on it but would be\n> interested in other people's experiences.\n>\n> For the figures part, I think I read somewhere there exists some\n> statistics on Git usage for Linux kernel. Is this correct ? If true,\n> where could I find them ?\n>\n> Thanks in advance for answering my (maybe pointless) questions and for\n> producing such a nice piece of software.\n\nthe one thing that I have seen P4 reported as handling better than git is \nthe case where the repository is very large. this is typically not caused \nby lots of lines of code, but by checking in lots of binary blobs to the \nrepository.\n\nDavid Lang\n"},{"id":"118985","messageId":"m3fxcg3473.fsf@localhost.localdomain","threadId":"20263","inReplyTo":"85ljm84lat.fsf@oqube.com","subject":"Re: From P4 to Git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-28T21:10:16Z","receivedAt":"2009-07-28T21:10:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Arnaud Bailly <abailly@oqube.com> writes:\n\n> I am investigating the use of Git in a setting where we:\n>  1. branches a lot\n\nGit handles large number of branches very well.  \n\nThe workflow of topic branches, where each new feature is developed on\nseparate branch, which can be individually picked to be merged (or\nnot) is used by git itself, for example.\n\n>  2. have a very large codebase\n\nHow large codebase?  What it means \"large codebase\"?  Large number of\nfiles, or files large in size (usually binary)?\n\n\nGit can deal comfortably with codebase of the size of Linux kernel.\nPerl 5 core was converted from Perforce to Git.\n\nBut git is snapshot based, not changeset based, and treats project\n(repository) as whole, not as a combination of single file histories.\nThis means that it would be unproductive to use 'everything in single\nrepository' approach.  If your codebase is of the size of whole KDE\ntree, or the whole GNOME tree, you would need to organize it and split\nit into smaller, reasonably sized repositories (you can urganize them\nback together in a superproject using submodules).\n\nIf ou can't do that, you would probably be better with other version\ncontrol system, like Subversion (IIRC both KDE and OpenOffice.org\nchosen this free centralized version control system).\n\n\nBecause Git was created to version control source code, it might not\nwork well with large binary files, meaning that performance would\nsuffer.  \n\nPartial checkouts (where you check out only part of repository) were\nproposed, but are not implemented yet.  Neither did lazy clone /\nremote alternates idea.  You can do a bit with undocumented `delta`\ngitattribute, and with putting large binary blobs into separate\npackfile, which is 'kept' (using *.keep file) against repacking, and\nperhaps available on networked filesystem.\n\nI think you can use refs/replace/ mechanizm (IIRC currently in 'pu',\n(proposed updates) branch) to have two versions of repository: one\nwith binary blobs and one without.\n\n> \n> Given Git is developed to handle these 2 issues, I suspect it would be a\n> very good choice, but I need to gather some experiments feedback and\n> hard figures on how Git performs (storage use, necessary\n> bandwidth/resources, maintainance of repositories, cleanup & gc...).\n> \n> For the experiment part, I am started working on it but would be\n> interested in other people's experiences.\n\nCheck out Sam Vilain (?) reports from converting Perl 5 repository\nfrom Perforce to Git.\n\n> \n> For the figures part, I think I read somewhere there exists some\n> statistics on Git usage for Linux kernel. Is this correct ? If true,\n> where could I find them ? \n\nThere is GitStat project: http://mirror.celinuxforum.org/gitstat/\n\nThere was also Git-Statistics project at Google Summer of Code 2008\nwhich repository can be found at http://repo.or.cz/w/git-stats.git\nSee http://git.or.cz/gitwiki/SoC2008Projects\n\n> \n> Thanks in advance for answering my (maybe pointless) questions and for\n> producing such a nice piece of software.\n> -- \n> Arnaud Bailly\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"119224","messageId":"200907311122.43918.jnareb@gmail.com","threadId":"20263","inReplyTo":"85r5vxbd8e.fsf@oqube.com","subject":"Re: From P4 to Git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-31T09:22:42Z","receivedAt":"2009-07-31T09:22:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I have re-added git mailing list to Cc.\n\nOn Fri, 31 July 2009, Arnaud Bailly wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n>>\n>>>  2. have a very large codebase\n>>\n>> How large codebase?  What it means \"large codebase\"?  Large number of\n>> files, or files large in size (usually binary)?\n> \n> Mostly lot of source files, amounting to about 9 MLOCs of mixed\n> languages source.\n> \n>> Git can deal comfortably with codebase of the size of Linux kernel.\n>> Perl 5 core was converted from Perforce to Git.\n> \n> I guess we are in the same order of magnitude than kernel.\n\nLinux kernel, for development of which git was initially designed,\nis around 7.5M LoC of code (10M LoC with comments and blank lines)[1].\nThe performance for such large codebase has to be good (at least on\nLinux and other POSIX systems), as good performance was one of goal\ndecisions of git.\n\nPerl 5 core, which version control history was converted from Perforce\nto Git in December 2008[1][2] by Sam Vilain (you might want to take\na look how it was done; unfortunately it seems that Sam Vilain blog\nvanished from Internet), is 2.3M LoC of mixed language code (mainly\nPerl and C, with twice as much Perl), so it is smaller than yours\ncodebase.\n\n[1] According to OSS software metric site Ohloh (http://www.ohloh.net)\n[2] http://news.perlfoundation.org/2008/12/perl_5_development_now_on_git.html\n[3] http://use.perl.org/article.pl?sid=08/12/22/0830205\n\n>> But git is snapshot based, not changeset based, and treats project\n>> (repository) as whole, not as a combination of single file histories.\n>> This means that it would be unproductive to use 'everything in single\n>> repository' approach.  If your codebase is of the size of whole KDE\n>> tree, or the whole GNOME tree, you would need to organize it and split\n>> it into smaller, reasonably sized repositories (you can urganize them\n>> back together in a superproject using submodules).\n> \n> That's my biggest concern. We are actually using a single tree repository\n> approach with lot of branches. What led me to Git at first was the ease\n> of branching and merging. I used branching and merging with Subversion\n> and its painful.\n\nSo it looks like you wouldn't _need_ to split source tree into separate\nsmaller repositories for performance reasons.  Still it might be good\nidea to put separate (sub)projects into separate repositories.  But\nI guess you can do that even at later time (although it would be best\nto do this upfront).\n\nBranching and merging in Git is very easy (with Subversion 1.5 merging\nis supposedly to get easier).  Git itself uses 'topic branches' workflow,\nwhere each feature (each series of patches) gets its own branch, and\nbranches are cherry-picked to be merged (or to be dropped, or replaced\nby newer version of series).\n \n>> There is GitStat project: http://mirror.celinuxforum.org/gitstat/\n\nWhich follows Linux kernel.  There are also some GitStat deployments\ntracking other code.\n\n>> There was also Git-Statistics project at Google Summer of Code 2008\n>> which repository can be found at http://repo.or.cz/w/git-stats.gitSee http://git.or.cz/gitwiki/SoC2008Projects\n>>\n> \n> Great.\n\nAnd there are tools such as Ohloh, which do software metric, and some\nof code is available.  GitHub hosting site also offers some software \nmetric / statistic tools in its web interface; I don't know about other\nsites such as Gitorious or InDefero.  Gitweb currently doesn't offer any\nstatistics.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"119252","messageId":"81b0412b0907310414x7157fecey947da960ff8be1cc@mail.gmail.com","threadId":"20263","inReplyTo":"200907311122.43918.jnareb@gmail.com","subject":"Re: From P4 to Git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-07-31T11:14:40Z","receivedAt":"2009-07-31T11:14:40Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Fri, Jul 31, 2009 at 11:22, Jakub Narebski<jnareb@gmail.com> wrote:\n>> That's my biggest concern. We are actually using a single tree repository\n>> approach with lot of branches. What led me to Git at first was the ease\n>> of branching and merging. I used branching and merging with Subversion\n>> and its painful.\n>\n> So it looks like you wouldn't _need_ to split source tree into separate\n> smaller repositories for performance reasons.  Still it might be good\n> idea to put separate (sub)projects into separate repositories.  But\n> I guess you can do that even at later time (although it would be best\n> to do this upfront).\n\nIt looks like they use P4 branches. Which are NOT branches as Git\nunderstands it (a line of history). The P4 \"branches\" are just directories\nwith some metadata regarding recording where the data in the directory\nwere before an act of \"branching\" (just a server-side recursive copy).\n\nIn this case (and this must be, as there are no other branches in P4),\nthey'll have to split their repository.\n"},{"id":"119378","messageId":"1249197415.6377.4.camel@maia.lan","threadId":"20263","inReplyTo":"200907311122.43918.jnareb@gmail.com","subject":"Re: From P4 to Git","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-02T07:16:55Z","receivedAt":"2009-08-02T07:16:55Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2009-07-31 at 11:22 +0200, Jakub Narebski wrote:\n> Sam Vilain (you might want to take\n> a look how it was done; unfortunately it seems that Sam Vilain blog\n> vanished from Internet)\n\nYou think that was unfortunate?  Wow maybe I should pull finger and get\nsomething back up again :-).  Didn't try since the drupal blog I had\nfinally bitrot, silly php.\n\nSo if you're looking for the actual importer ... google git-p4raw,\nshould be on http://utsl.gen.nz/gitweb/ or http://git.catalyst.net.nz/gw\n\nSam\n"},{"id":"119397","messageId":"4A76967B.7080502@vilain.net","threadId":"20263","inReplyTo":"81b0412b0907310414x7157fecey947da960ff8be1cc@mail.gmail.com","subject":"Re: From P4 to Git","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-03T07:49:15Z","receivedAt":"2009-08-03T07:49:15Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Alex Riesen wrote:\n>> So it looks like you wouldn't _need_ to split source tree into separate\n>> smaller repositories for performance reasons.  Still it might be good\n>> idea to put separate (sub)projects into separate repositories.  But\n>> I guess you can do that even at later time (although it would be best\n>> to do this upfront).\n>>     \n>\n> It looks like they use P4 branches. Which are NOT branches as Git\n> understands it (a line of history). The P4 \"branches\" are just directories\n> with some metadata regarding recording where the data in the directory\n> were before an act of \"branching\" (just a server-side recursive copy).\n>\n> In this case (and this must be, as there are no other branches in P4),\n> they'll have to split their repository.\n\np4's branches are 'close enough'.  My tool travels through the history\nof the repository forwards, detects paths where new content was placed\nand calls those roots.  When branching is detected (recorded\nfile-by-file in perforce), it puts the branch source as a new parent. \nWhen branches are 'integrated', it makes a fuzzy decision based on the\nnumber of outstanding merges it thinks are due, also based on a merge\nbase calculation on the current view of the derived history.  It allows\nmanual correction of this fuzzy information, and arbitrary grafting\nalong the way.  Discrepancies between the fuzzy decision and the actual\nintegration records are recorded in the commit log along with other\nmetadata including the commit ID.\n\nSam\n"},{"id":"119399","messageId":"81b0412b0908030147i34a7440dg982c7a6e7dc51bca@mail.gmail.com","threadId":"20263","inReplyTo":"4A76967B.7080502@vilain.net","subject":"Re: From P4 to Git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-08-03T08:47:29Z","receivedAt":"2009-08-03T08:47:29Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Mon, Aug 3, 2009 at 09:49, Sam Vilain<sam@vilain.net> wrote:\n> Alex Riesen wrote:\n>>> So it looks like you wouldn't _need_ to split source tree into separate\n>>> smaller repositories for performance reasons.  Still it might be good\n>>> idea to put separate (sub)projects into separate repositories.  But\n>>> I guess you can do that even at later time (although it would be best\n>>> to do this upfront).\n>>>\n>>\n>> It looks like they use P4 branches. Which are NOT branches as Git\n>> understands it (a line of history). The P4 \"branches\" are just directories\n>> with some metadata regarding recording where the data in the directory\n>> were before an act of \"branching\" (just a server-side recursive copy).\n>>\n>> In this case (and this must be, as there are no other branches in P4),\n>> they'll have to split their repository.\n>\n> p4's branches are 'close enough'.  My tool travels through the history\n> of the repository forwards, detects paths where new content was placed\n> and calls those roots.  When branching is detected (recorded\n> file-by-file in perforce), it puts the branch source as a new parent.\n> When branches are 'integrated', it makes a fuzzy decision based on the\n> number of outstanding merges it thinks are due, also based on a merge\n> base calculation on the current view of the derived history.  It allows\n> manual correction of this fuzzy information, and arbitrary grafting\n> along the way.  Discrepancies between the fuzzy decision and the actual\n> integration records are recorded in the commit log along with other\n> metadata including the commit ID.\n\nSounds dangerous. And interesting...\n\nIs it an import-once tool, or can the process be restarted? (because it looks\nlike the script needs a complicated setup).\nCan it be used from a client machine? And more importantly:\ncan the branches be found from incomplete history,\nrestricted by path and changelist range? (because, in a corporate\nsetup, clients seldom have full access to all data).\n"},{"id":"119401","messageId":"1249299010.7164.8.camel@maia.lan","threadId":"20263","inReplyTo":"81b0412b0908030147i34a7440dg982c7a6e7dc51bca@mail.gmail.com","subject":"Re: From P4 to Git","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-03T11:30:10Z","receivedAt":"2009-08-03T11:30:10Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Mon, 2009-08-03 at 10:47 +0200, Alex Riesen wrote:\n> Is it an import-once tool, or can the process be restarted? (because it looks\n> like the script needs a complicated setup).\n\nIt's fully restartable.  Not only that but it uses transaction\nprotection to make sure that its internal state doesn't get corrupted\nwhen performing the various options.\n\n> Can it be used from a client machine?\n>  And more importantly:\n> can the branches be found from incomplete history,\n> restricted by path and changelist range? (because, in a corporate\n> setup, clients seldom have full access to all data).\n\nNo, it's server only.  I think I did get around to implementing not having\nto go through all the stages for branches you didn't care to import.  It's\ndifficult though, the stage which correlates those thousands of 'integrate'\nrecords is never going to be fast.  Be prepared to tune your postgres - add\nlots of shared_buffers and sort memory if your project is as large as Perl.\n\nSam.\n"},{"id":"119403","messageId":"81b0412b0908030650oc39f4a3s7c059e300b65addb@mail.gmail.com","threadId":"20263","inReplyTo":"1249299010.7164.8.camel@maia.lan","subject":"Re: From P4 to Git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-08-03T13:50:14Z","receivedAt":"2009-08-03T13:50:14Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Mon, Aug 3, 2009 at 13:30, Sam Vilain<sam@vilain.net> wrote:\n> On Mon, 2009-08-03 at 10:47 +0200, Alex Riesen wrote:\n>> Is it an import-once tool, or can the process be restarted? (because it looks\n>> like the script needs a complicated setup).\n>\n> It's fully restartable.  Not only that but it uses transaction\n> protection to make sure that its internal state doesn't get corrupted\n> when performing the various options.\n\n\"varios options\"? Operations? As when working on a live server?\nAren't P4 changelist numbers always increasing? Or you mean\nthe protection against multiple running instances of p4raw,\nso it is also parallelizable?\n\n>> Can it be used from a client machine?\n>>  And more importantly:\n>> can the branches be found from incomplete history,\n>> restricted by path and changelist range? (because, in a corporate\n>> setup, clients seldom have full access to all data).\n>\n> No, it's server only. ...\n\nDarn. I hoped it wasn't. Can't play with it, then.\n\n> ... I think I did get around to implementing not having\n> to go through all the stages for branches you didn't care to import.  It's\n> difficult though, the stage which correlates those thousands of 'integrate'\n> records is never going to be fast.\n\nMaybe if it is done locally, it can be improved? You seem to use the\nPostgre for lookups, right?\n\n> Be prepared to tune your postgres - add lots of shared_buffers and\n> sort memory if your project is as large as Perl.\n\nMine isn't, but it is thrown on a server with a lot of others. Some branched\noff mine, some integrate it, some just copied and re-introduced into repository\n(these will probably worked with manually forever). There is also a small\nproblem of different P4 servers, hosting code from the same project (they\npull different repos together on client, imagine that!)\n\nAnd all of them go back for 5-6 years, so it is kind of largish (not to mention\na mess of binaries).\n\nSome branches I hope to merge back. I do that already, but it is a lot of\nmanual work (I use that git-p4-import.bat I posted early, which only can\nimport a sequence of changelists with files they touch).\n\nThat's were I hoped your project could help. I thought, if I pull in all the\nneeded changelists (selected by path/CL), there may be a way to\nrecreate a mergeable history out of this dump. At least, one involving less\nlabor then I have to do now.\n"},{"id":"119429","messageId":"1249331540.12801.10.camel@maia.lan","threadId":"20263","inReplyTo":"81b0412b0908030650oc39f4a3s7c059e300b65addb@mail.gmail.com","subject":"Re: From P4 to Git","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-03T20:32:20Z","receivedAt":"2009-08-03T20:32:20Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Mon, 2009-08-03 at 15:50 +0200, Alex Riesen wrote:\n> On Mon, Aug 3, 2009 at 13:30, Sam Vilain<sam@vilain.net> wrote:\n> > On Mon, 2009-08-03 at 10:47 +0200, Alex Riesen wrote:\n> >> Is it an import-once tool, or can the process be restarted? (because it looks\n> >> like the script needs a complicated setup).\n> >\n> > It's fully restartable.  Not only that but it uses transaction\n> > protection to make sure that its internal state doesn't get corrupted\n> > when performing the various options.\n> \n> \"varios options\"? Operations? As when working on a live server?\n> Aren't P4 changelist numbers always increasing? Or you mean\n> the protection against multiple running instances of p4raw,\n> so it is also parallelizable?\n\nThe \"live\" parts are never touched - only the write-only files that\nperforce writes; and the rcs files are read using rcs.\n\nWhat I was referring to by \"various options\" was the commands in the\nprogram which perform the migration.  It's a multi-step process - load\nthe metadata from perforce 'load', import the file images to git blobs\n'export-blobs', trace through the path structure and decide which parts\nare the roots, and make parents 'find-branches', etc.  All parts are\nfully transaction protected, restartable and rewindable.  It also means\nthat if a command crashes that you are left in a sane state.  I had to\nbuild it like that to keep my sanity writing and using it :-).  After\nall it was something of a reverse engineering of Perforce's internals.\n\nAll you need is the RCS backing files, a 'checkpoint' and (optionally)\n'journal' files.  No access to the live perforce DBs is required.\n\n> > No, it's server only. ...\n> Darn. I hoped it wasn't. Can't play with it, then.\n\nYeah, in theory you could derive the internal table information by\nissuing zillions of 'p4 integrated', 'p4 filelog' commands etc.  I've\nwritten p4raw sub-commands which can produce the output of those\ncommands but not tried to go the other way; I wasn't interested.\n\n> > ... I think I did get around to implementing not having\n> > to go through all the stages for branches you didn't care to import.  It's\n> > difficult though, the stage which correlates those thousands of 'integrate'\n> > records is never going to be fast.\n> Maybe if it is done locally, it can be improved? You seem to use the\n> Postgre for lookups, right?\n\nI'm sure that the queries could be improved, but Postgres is actually\nquite good at crunching the numbers.  It's just a lot of data to crunch.\n\n> That's were I hoped your project could help. I thought, if I pull in all the\n> needed changelists (selected by path/CL), there may be a way to\n> recreate a mergeable history out of this dump. At least, one involving less\n> labor then I have to do now.\n\nYeah... well the design of my tool is that it needs to have the perforce\ninternal information.  But really you can probably consider the\nconverter orphaned, I have no current need to work on it; it served a\npurpose, which was converting perl's perforce to perl.git, and that's\nhistory now.\n\nSam\n"},{"id":"119431","messageId":"43d8ce650908031437h3c2e899ey849053d7428a3105@mail.gmail.com","threadId":"20263","inReplyTo":"m3fxcg3473.fsf@localhost.localdomain","subject":"Re: From P4 to Git","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-08-03T21:37:05Z","receivedAt":"2009-08-03T21:37:05Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/7/29 Jakub Narebski <jnareb@gmail.com>:\n> If ou can't do that, you would probably be better with other version\n> control system, like Subversion (IIRC both KDE and OpenOffice.org\n> chosen this free centralized version control system).\n\nGoing a bit off topic - but to clarify, KDE hasn't really 'chosen' svn\nover git, it's that we haven't switched to git _yet_. It just takes\ntime.  We already have trial projects (Amarok, for example, has\nswitched to git to lead the way) and I'm not sure if git submodule\nsupport is mature enough, but baring any major problems we will\nswitch.\n\nJohn\n"},{"id":"119433","messageId":"20090803215137.GC3759@blimp.localdomain","threadId":"20263","inReplyTo":"1249331540.12801.10.camel@maia.lan","subject":"Re: From P4 to Git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-08-03T21:51:37Z","receivedAt":"2009-08-03T21:51:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Sam Vilain, Mon, Aug 03, 2009 22:32:20 +0200:\n> On Mon, 2009-08-03 at 15:50 +0200, Alex Riesen wrote:\n> > \"varios options\"? Operations? As when working on a live server?\n> > Aren't P4 changelist numbers always increasing? Or you mean\n> > the protection against multiple running instances of p4raw,\n> > so it is also parallelizable?\n> \n> The \"live\" parts are never touched - only the write-only files that\n> perforce writes; and the rcs files are read using rcs.\n\nI always felt Perforce had a touch of pure evil...\n\n> All you need is the RCS backing files, a 'checkpoint' and (optionally)\n> 'journal' files.  No access to the live perforce DBs is required.\n\nWhich in my case is all the same. I don't dare to ask, frankly.\n\n> > That's were I hoped your project could help. I thought, if I pull in all the\n> > needed changelists (selected by path/CL), there may be a way to\n> > recreate a mergeable history out of this dump. At least, one involving less\n> > labor then I have to do now.\n> \n> Yeah... well the design of my tool is that it needs to have the perforce\n> internal information.  But really you can probably consider the\n> converter orphaned, I have no current need to work on it; it served a\n> purpose, which was converting perl's perforce to perl.git, and that's\n> history now.\n\nThanks anyway for bringing it to public attention. At least, it is\nknown to be done once. Could be an encouragement for next one to try.\nA guide, even.\n"},{"id":"119447","messageId":"4A7780FC.6090606@vilain.net","threadId":"20263","inReplyTo":"20090803215137.GC3759@blimp.localdomain","subject":"Re: From P4 to Git","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-04T00:29:48Z","receivedAt":"2009-08-04T00:29:48Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Alex Riesen wrote:\n>> The \"live\" parts are never touched - only the write-only files that\n>> perforce writes; and the rcs files are read using rcs.\n>>     \n>\n> I always felt Perforce had a touch of pure evil...\n>   \n\nPerforce is not really that evil imho. It uses rcs for what it's good at\n- storing file revisions. All the metadata it kept in table stores which\ncould be checkpointed and journalled like a regular database. Simple,\nelegant, fast, robust. Overall I'd say it was a well engineered piece of\nsoftware which delivered great benefits to its users, far less evil than\nCVS or Subversion. Which is funny because Subversion rips off many\nconcepts from Perforce including the 'branching is just copying' idea.\nBut they left behind the integration system. Even now svn's merging\nsupport can't even handle merging correctly in the face of branched\nbranches, or so I hear. That's evil - pretending to have a feature\nsolved when they haven't even met the standard set by bzr, hg, mtn, git,\netc.\n\nSam\n"},{"id":"119490","messageId":"85ljlzvjyp.fsf@oqube.com","threadId":"20263","inReplyTo":"200907311122.43918.jnareb@gmail.com","subject":"Re: From P4 to Git","fromName":"Arnaud Bailly","fromEmail":"abailly@oqube.com","sentAt":"2009-08-04T12:31:42Z","receivedAt":"2009-08-04T12:31:42Z","isPatch":false,"sender":{"key":"abailly@oqube.com","avatar":null},"body":"Thanks all for your detailed answers.\n\nPlaying with git on various environments, I have a couple more questions\nthat I could not (quickly) find answers on the web.\n 1. when checkout-ing on NTFS, I got all my files marked as changed\n because of file permissions set from 100644 to 100755. I see there is a\n config flag about file permissions (core.sharedRepository ?) but not\n sure how to use it\n 2. I am working with NTFS on a truecrypt managed USB HD and I noticed\n an order of magnitude difference in speed (ie. about 10x for checkout\n of 50k files) between this and my ext3 FS  on laptop HD. Is this\n expected ? Some people here reported slowness on non-encrypted NTFS and\n I think I read a couple of web fragments about speed difference between\n the 2. WDYT ?\n\nRegards,\n-- \nArnaud Bailly -- OQube\n<software engineering>\nhttp://www.oqube.com/\n"},{"id":"119491","messageId":"20090804123508.GA26373@m62s10.vlinux.de","threadId":"20263","inReplyTo":"85ljlzvjyp.fsf@oqube.com","subject":"Re: From P4 to Git","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2009-08-04T12:35:08Z","receivedAt":"2009-08-04T12:35:08Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Tue, Aug 04, 2009 at 02:31:42PM +0200, Arnaud Bailly wrote:\n> Thanks all for your detailed answers.\n> \n> Playing with git on various environments, I have a couple more questions\n> that I could not (quickly) find answers on the web.\n>  1. when checkout-ing on NTFS, I got all my files marked as changed\n>  because of file permissions set from 100644 to 100755. I see there is a\n>  config flag about file permissions (core.sharedRepository ?) but not\n>  sure how to use it\n\nNo, that config flag is for sharing a repository with other people. You want\nsomething like core.filemode = false\n\n-Peter\n"}]}