{"thread":{"id":"5454","subject":"Mozilla version control requirements and git","startedAt":"2006-09-02T14:31:44Z","lastAt":"2006-09-04T01:43:57Z","messageCount":9,"participants":["Jon Smirl","Martin Langhoff","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26221","messageId":"9e4733910609020731k25ce3a0aw7a84542f8cd516f6@mail.gmail.com","threadId":"5454","inReplyTo":null,"subject":"Mozilla version control requirements and git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-02T14:31:44Z","receivedAt":"2006-09-02T14:31:44Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"The Mozilla people have a web page describing what they are looking\nfor in a new version control system. How does git stack up?\n\nhttp://wiki.mozilla.org/Version_Control_System_Requirements\n\nThey have also recently put up a Subversion server for limited use.\n\nhttp://weblogs.mozillazine.org/preed/2006/08/subversive_subversion_conversi.html\n\n-- \nJon Smirl\njonsmirl@gmail.com\n\n-- \nVGER BF report: U 0.506426\n"},{"id":"26245","messageId":"46a038f90609021819v6d427f0eh69bc13b30ef6b692@mail.gmail.com","threadId":"5454","inReplyTo":"9e4733910609020731k25ce3a0aw7a84542f8cd516f6@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-09-03T01:19:41Z","receivedAt":"2006-09-03T01:19:41Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/3/06, Jon Smirl wrote:\n> The Mozilla people have a web page describing what they are looking\n> for in a new version control system. How does git stack up?\n\nHi Jon,\n\nyou've been playing with GIT quite a bit by now, so I guess you know\nthe answer ;-) Is there anything in particular you are wondering\nabout?\n\nThe one item that sticks out for me as not there is ACLs, but access\ncontrols can be implemented in hooks for direct pushes. Maintain an\n.htaccess-like file and have a perl script to check it on pushes to\nthe repo.\n\nOh, and \"partial tree pulls for localisers\". Perhaps git-cvsserver can\nhelp there? Localisers can just use TortoiseCVS and get a checkout of\nthe language pack subdir.\n\ncheers,\n\n\n\nmartin\n\n-- \nVGER BF report: U 0.544429\n"},{"id":"26246","messageId":"9e4733910609022029q9cb9ba9m87cbc37e8d6f4ad7@mail.gmail.com","threadId":"5454","inReplyTo":"46a038f90609021819v6d427f0eh69bc13b30ef6b692@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-03T03:29:23Z","receivedAt":"2006-09-03T03:29:23Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/2/06, Martin Langhoff wrote:\n> On 9/3/06, Jon Smirl wrote:\n> > The Mozilla people have a web page describing what they are looking\n> > for in a new version control system. How does git stack up?\n>\n> Hi Jon,\n>\n> you've been playing with GIT quite a bit by now, so I guess you know\n> the answer ;-) Is there anything in particular you are wondering\n> about?\n\nShallow clones are a big problem. We have Mozilla down to 450MB is\ngit, but that is still gigantic for anyone doing an initial check out,\nespecially if they don't have good broadband. It is over 10x the data\nthat CVS brings down. Even without doing shallow clones git still\nneeds to be modified to restart an interrupted pack transfer.\n\n>\n> The one item that sticks out for me as not there is ACLs, but access\n> controls can be implemented in hooks for direct pushes. Maintain an\n> .htaccess-like file and have a perl script to check it on pushes to\n> the repo.\n\nI don't see ACLs as that big an issue. If you convert to model where\neveryone has their own repo and you just push changesets at each\nother, ACLs are much less important. You need ACLs when 2,000 people\nhave commit privs.\n\n>\n> Oh, and \"partial tree pulls for localisers\". Perhaps git-cvsserver can\n> help there? Localisers can just use TortoiseCVS and get a checkout of\n> the language pack subdir.\n\nPartial repo pulls and an issue to. The mozilla repo has much more\nthan a browser in it, it also has a large mail/news program. A partial\nrepo pull may not be what is needed for git, instead git needs a\npartial repo checkout.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n\n-- \nVGER BF report: U 0.827771\n"},{"id":"26249","messageId":"ede6in$b9u$1@sea.gmane.org","threadId":"5454","inReplyTo":"9e4733910609022029q9cb9ba9m87cbc37e8d6f4ad7@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-03T09:17:13Z","receivedAt":"2006-09-03T09:17:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n>> Oh, and \"partial tree pulls for localisers\". Perhaps git-cvsserver can\n>> help there? Localisers can just use TortoiseCVS and get a checkout of\n>> the language pack subdir.\n> \n> Partial repo pulls and an issue to. The mozilla repo has much more\n> than a browser in it, it also has a large mail/news program. A partial\n> repo pull may not be what is needed for git, instead git needs a\n> partial repo checkout.\n\nOr better support for subprojects.\n\nI think you can fake subproject support using separate repositories\nfor subprojects, in the directory matching the one in the whole project,\nand the project repository, where we pull/push subprojects into.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n\n\n-- \nVGER BF report: U 0.877495\n"},{"id":"26262","messageId":"9e4733910609030646k6c722068m30f0e05fccc9c3c5@mail.gmail.com","threadId":"5454","inReplyTo":"ede6in$b9u$1@sea.gmane.org","subject":"Re: Mozilla version control requirements and git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-03T13:46:21Z","receivedAt":"2006-09-03T13:46:21Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/3/06, Jakub Narebski wrote:\n> Jon Smirl wrote:\n>\n> >> Oh, and \"partial tree pulls for localisers\". Perhaps git-cvsserver can\n> >> help there? Localisers can just use TortoiseCVS and get a checkout of\n> >> the language pack subdir.\n> >\n> > Partial repo pulls and an issue to. The mozilla repo has much more\n> > than a browser in it, it also has a large mail/news program. A partial\n> > repo pull may not be what is needed for git, instead git needs a\n> > partial repo checkout.\n>\n> Or better support for subprojects.\n>\n> I think you can fake subproject support using separate repositories\n> for subprojects, in the directory matching the one in the whole project,\n> and the project repository, where we pull/push subprojects into.\n\nYou can't really fake it. Many of the projects in Mozilla are\ndependent on each other. If you break them up into separate\nrepositories you lose the ability to do a cross project commit. This\nis common when you are changing an interface between the subprojects.\n\nWould it make sense for git to treat a tree of projects like you\ndescribe as a single entity? So a commit would transparently commit to\nall of the subprojects. Maybe the commit entry's sha1 could be set up\nso that it would be identical in all subprojects. That would let you\nstring them back together.\n\n> --\n> Jakub Narebski\n> Warsaw, Poland\n> ShadeHawk on #git\n>\n>\n>\n> --\n> VGER BF report: U 0.877495\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n\n-- \nVGER BF report: S 0.995201\n"},{"id":"26265","messageId":"200609031742.13902.jnareb@gmail.com","threadId":"5454","inReplyTo":"9e4733910609030646k6c722068m30f0e05fccc9c3c5@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-03T15:42:13Z","receivedAt":"2006-09-03T15:42:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 03-09-2006 15:46, Jon Smirl wrote:\n> On 9/3/06, Jakub Narebski wrote:\n> > Jon Smirl wrote:\n> >\n> > >> Oh, and \"partial tree pulls for localisers\". Perhaps git-cvsserver can\n> > >> help there? Localisers can just use TortoiseCVS and get a checkout of\n> > >> the language pack subdir.\n> > >\n> > > Partial repo pulls and an issue to. The mozilla repo has much more\n> > > than a browser in it, it also has a large mail/news program. A partial\n> > > repo pull may not be what is needed for git, instead git needs a\n> > > partial repo checkout.\n> >\n> > Or better support for subprojects.\n> >\n> > I think you can fake subproject support using separate repositories\n> > for subprojects, in the directory matching the one in the whole project,\n> > and the project repository, where we pull/push subprojects into.\n> \n> You can't really fake it. Many of the projects in Mozilla are\n> dependent on each other. If you break them up into separate\n> repositories you lose the ability to do a cross project commit. This\n> is common when you are changing an interface between the subprojects.\n> \n> Would it make sense for git to treat a tree of projects like you\n> describe as a single entity? So a commit would transparently commit to\n> all of the subprojects. Maybe the commit entry's sha1 could be set up\n> so that it would be identical in all subprojects. That would let you\n> string them back together.\n\nScratch that. You can fake subproject support using something similar\nto the way Junio works with TODO branch. Namely, separate repositories\nfor subprojects, each as if it would start from it's own directory\n(although you can manage without that, it only would be slightly harder\nto set it up), and main repository working directory composed from\nsubproject repositories checked out to correct place. Add to this\ningnoring object database (i.e. .git repositories), and you have whole\nrepository... where you can do whole repository commits to.\n\nE.g. the following directory structure\n\n\tmain-project/\n\tmain-project/.git\n\tmain-project/subproject/\n\tmain-project/subproject/.git\n\tmain-project/subproject/...subproject files...\n\nwhere second .git is in .gitignore or info/excludes, but the subrpoject/\ndirectory itself isn't.\n\n\nIf this is not enough, check out ideas in Subpro.txt in the 'todo' branch\nin git repository. It adds additional 'bind' header... the implementation\n(search for 'gitlink') were if I remember correctly never fully implemented\nand is not in git, although parts of it like git-read-tree and \ngit-write-tree --prefix option made it.\n http://www.kernel.org/git/?p=git/git.git;a=blob;f=Subpro.txt;hb=todo\n\n\nAs commit id depends on the contents, including _parents_ and _tree_,\nit is I think impossible to set commit entry sha1 to be identical.\n\nP.S. I just hope that it would pass VGER filter. I don't have much luck\nwith it lately...\n-- \nJakub Narebski\nPoland\n\n-- \nVGER BF report: S 0.994192\n"},{"id":"26266","messageId":"46a038f90609031440s33e66499x51026aa6062566d2@mail.gmail.com","threadId":"5454","inReplyTo":"9e4733910609030646k6c722068m30f0e05fccc9c3c5@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-09-03T21:40:17Z","receivedAt":"2006-09-03T21:40:17Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/4/06, Jon Smirl wrote:\n> You can't really fake it. Many of the projects in Mozilla are\n> dependent on each other. If you break them up into separate\n> repositories you lose the ability to do a cross project commit. This\n> is common when you are changing an interface between the subprojects.\n\nIn many projects this is handled by having tags and generally\nversioning modules and interfaces. Being independent gives the\nsubprojects/modules a lot more freedom to work/branch on wild\ntangents, and the versioned interfaces mean that -- with the\ncontraints of the versioned interfaces -- you can mix and match\nbranches/releases of the different subprojects.\n\nIn short, I'd definitely break those up :-)\n\ncheers,\n\n\n\n\nmartin\n\n-- \nVGER BF report: U 0.513231\n"},{"id":"26276","messageId":"7v3bb8tuse.fsf@assigned-by-dhcp.cox.net","threadId":"5454","inReplyTo":"9e4733910609022029q9cb9ba9m87cbc37e8d6f4ad7@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-03T23:06:09Z","receivedAt":"2006-09-03T23:06:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jon Smirl\" writes:\n\n> Partial repo pulls and an issue to. The mozilla repo has much more\n> than a browser in it, it also has a large mail/news program. A partial\n> repo pull may not be what is needed for git, instead git needs a\n> partial repo checkout.\n\nThat does not contradict with the underlying data model of git,\nand it would certainly be possible with a specialized Porcelain.\n\nSince git tracks the entire tree, the tree object contained in\nthe commit you create _must_ describe the entire project tree,\nbut that does not necessarily mean that your working tree needs\nto have the entire tree checked out.\n\nThe git corelevel is designed to be operable with sparsely\npopulated working tree, and the problem you are seeing is\nprimarily coming from the fact that some wrappers you are seeing\nas \"git UI\" are specifically done to help workflows that _wants_\nto have fully populated working tree (e.g. \"git commit -a\" and\n\"git checkout\"). There are other wrappers that are designed to\nwork well in sparsely populated working tree, including \"git-am\"\nand \"git-merge\". They should be usable pretty much as they are.\n\nTo support \"narrow checkout\" workflow, some wrappers either need\nto be told about the \"interesting area\", or a set of different\nwrappers specifically designed to support \"narrow checkout\"\nworkflow can be written. I am not sure which is more desirable.\nI have a gut feeling that \"git commit\" can be used as is (you cd\ninto the area you are interested in, and say \"git commit .\"\ninstead of saying \"git commit -a\"), while it would be less\nconfusing to keep \"git checkout\" the whole-tree operation and\nhave a specialized porcelain for a narrow checkout, but this is\nme saying things without thinking things through.\n\nI imagine such a \"narrow checkout\" workflow Porcelain would work\nlike this:\n\n - the user tells it which parts of the whole project she is\n interested in.\n\n - when checking things out, the Porcelain populates the index\n in full [*1*] and then checks out only specified subtrees to\n the working tree.\n\n - when checking things in, the changes outside the specified\n area are ignored (well, outside there should be no files in\n working tree so ignoring them should be trivial). write-tree\n writes from the whole index and creates the tree object and\n then commit object just as usual. The net effect is that the\n parts outside the areas of interest stay the same as the\n previous HEAD commit, which is exactly what the user wanted\n anyway.\n\nYou could optimize the above further by populating the index\nsparsely as well (i.e. *1* above is not a requirement), but you\nwould need to merge in the changes made to that sparse index\ninto the full tree read from the HEAD commit before writing the\nnext tree object out anyway, so I doubt it is worth it.\n\n\n-- \nVGER BF report: U 0.842228\n"},{"id":"26279","messageId":"9e4733910609031843y79750bfcka5f0c350a6b24c9c@mail.gmail.com","threadId":"5454","inReplyTo":"46a038f90609031440s33e66499x51026aa6062566d2@mail.gmail.com","subject":"Re: Mozilla version control requirements and git","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-04T01:43:57Z","receivedAt":"2006-09-04T01:43:57Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/3/06, Martin Langhoff wrote:\n> On 9/4/06, Jon Smirl wrote:\n> > You can't really fake it. Many of the projects in Mozilla are\n> > dependent on each other. If you break them up into separate\n> > repositories you lose the ability to do a cross project commit. This\n> > is common when you are changing an interface between the subprojects.\n>\n> In many projects this is handled by having tags and generally\n> versioning modules and interfaces. Being independent gives the\n> subprojects/modules a lot more freedom to work/branch on wild\n> tangents, and the versioned interfaces mean that -- with the\n> contraints of the versioned interfaces -- you can mix and match\n> branches/releases of the different subprojects.\n>\n> In short, I'd definitely break those up :-)\n\nMozilla always ships as a complete system so there is no need to deal\nwith old versions of the pieces. Only the external interfaces are\nfrozen and versioned. This is similar to the Linux kernel. The user\nspace API is frozen, but when an internal device driver interface\nchanges all of the drivers in the kernel tree get updated in lock\nstep. Doing it this way removes a lot of overhead in maintaining\nbinary compatibility.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n\n-- \nVGER BF report: U 0.502564\n"}]}