{"thread":{"id":"13494","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","startedAt":"2008-05-12T18:54:16Z","lastAt":"2008-05-12T18:54:16Z","messageCount":1,"participants":["Justin Leung"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76748","messageId":"48289258.4010406@redback.com","threadId":"13494","inReplyTo":"20080511172549.28205.qmail@science.horizon.com","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Justin Leung","fromEmail":"jleung@redback.com","sentAt":"2008-05-12T18:54:16Z","receivedAt":"2008-05-12T18:54:16Z","isPatch":false,"sender":{"key":"jleung@redback.com","avatar":null},"body":"\nThanks George . \n\nis the git-cvsserver usable?\n\nI wanted to try it , but the inability to tag from the cvs side is not \nsomething that i can sell to my managements .\n\n Justin\n\n\nGeorge Spelvin wrote:\n>> - no incremental revision numbers (they are so scared of the 40hex SHA1)\n>>\n>> - Inability to reference without SHA1, they want simple numbering (ie,\n>>   version 100, 120, 120.1, 130.4.5)\n>>\n>> - Inability to refer to a file by a simple number\n>> (the backend guys will be confused by SHA1; they can't work with anything\n>> more than 4-5 digits)\n>>     \n>\n> This is Fundamentally Impossible in a distributed system.  You can try\n> to fake it, but you just end up with horrible corner cases.  Basically,\n> without a central server, who makes sure the incremental numbers are\n> assigned without collisions?\n>\n> HOWEVER:\n>\n> - You can use abbreviated SHA1 references.  5-6 digits will do to start,\n>   and you can go slightly longer when it becomes necessary.  Due to the\n>   \"birthday paradox\", you need a  hash code space larger than (number of\n>   objects)*(number of commits) to guarantee minimal chance of ambiguity.\n>\n> - You can have a post-commit hook that creates a simple numbered tag\n>   for each commit to the \"master\" repository.  You guys working\n>   independently will have to get a little fancier, but the \"master\"\n>   can have simple numbers.\n>\n> Between those two, it should be pretty reasonable.\n>\n> To get what you're asking for, you'd have to have a \"read-only git\" that\n> can ONLY pull from a centralized server that assigns the simple numbers,\n> and can never do local commits.\n>\n> I think that seems kind of pointless to the developers.  They'd like to\n> give your hardware guys the CHANCE to learn git, even if most only\n> use a very small subset of it.\n>\n> Is it that hard to tell them to \"ignore that box in gitk\"?\n>\n>   \n>> - Complexity of commands (although we can have warpper, but real git\n>>   commands for non-sw guys is not going to happen)\n>>\n>> Most hardware chip designers were using CVS since their first job.\n>> It suited the purpose very well.\n>>     \n>\n> You can use git-cvsserver to give them a CVS interface if that's what\n> they're happy with...\n>\n>   \n>> We don't use branches.\n>> Our model is strict forward with a centralized, one main branch model to\n>> avoid mistakes.\n>> We see branches as evil; some merges in Verilog codes means another 10+\n>> hours of simulation and regression.\n>>     \n>\n> I realize it's a big culture shock, but what git does with branch merges is\n> *exactly* what CVS does with \"cvs update\".  So there truly is no evil.\n> You can certainly use a \"git rebase\" style instead, but that's just style;\n> it doesn't change the basic underlying issue: as soon as you drop strict\n> locking and allow concurrent development, you have merges.\n>\n> \"cvs update\" basically does a \"git rebase\" and so doesn't show the merges\n> in the revision history, but they're there, and the possibility of\n> bugs is exactly the same.\n>\n> \"git push\" and \"cvs commit\" both have exactly the same rules: you\n> may not append to the server history unless you've fetched the\n> latest and resolved any conflicts.\n>\n> CVS branches are Horrible Awful Painful Things and I don't blame you\n> for avoiding them.  Git doesn't force you to use branches, but they're\n> downright pleasant to use, and provide a more accurate representation\n> in the development history of the actual concurrent development.\n>\n>   \n>> - 'git-show-branch' actually show reversed serialized version numbers (we\n>>   want it the other way, accending)\n>>     \n>\n> If you assign sequential version number tags on the central server, then\n> you want an option for it to use tags rather than just branch names.  That\n> will take care of this quite nicely.  Unfortunately, I can't seem to find\n> it right now.  Gitk does show tags in a very natural way.\n>   \n"}]}