{"thread":{"id":"13471","subject":"Verilog/ASIC development support is insufficient in git , help!","startedAt":"2008-05-11T05:08:43Z","lastAt":"2008-05-12T23:09:07Z","messageCount":11,"participants":["Justin Leung","Kevin Ballard","Christian MICHON","Jakub Narebski","Dana How","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76575","messageId":"BA7F9A3C7EDA4CDD99016093B0DB55C0@justinuTop","threadId":"13471","inReplyTo":"EB66C79C87CF49E59CB39EA4C286AE05@justinuTop","subject":"Verilog/ASIC development support is insufficient in git , help!","fromName":"Justin Leung","fromEmail":"jleung@redback.com","sentAt":"2008-05-11T05:08:43Z","receivedAt":"2008-05-11T05:08:43Z","isPatch":false,"sender":{"key":"jleung@redback.com","avatar":null},"body":"Hi all,\n\n* This email probably represent the whole hardware ASIC community about git \n*\n\nI'm evaluating Git as the replacement of CVS for the ASIC group in my \ncompany,\nbut things are moving along very bumpy.\n\nI (and many others doing the evaluation) love the tool dearly; we love the \nlocal repository and inter-db sync'ing .\nI see a lot of potential in productivity and changes in work model that \nhelps efficiency in ASIC dev.\n\nBUT, my managers, some veterans, and directors are EXTREMELY concerned about \nthe ease-of-use..\nso much that they are going to pick SVN !  uh-oh....i m serious =(\n\nAlot of people argued, why not SVN ? it's CVS++ and it's ease of use not a \nproblem when comparing to Git.\n\nhere are the things not fitting right in ASIC dev:\n\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, \nversion 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 \nmore than 4-5 digits)\n\n- Complexity of commands (although we can have warpper, but real git \ncommands for non-sw guys is not going to happen)\n\nMost hardware chip designers were using CVS since their first job.\nIt suited the purpose very well.\n\nMost RTL design veterans only use less then 5-6 cvs commands in their whole \nlife (LOL, i m serious) :\n\n$ cvs checkout\n$ cvs update\n$ cvs log\n$ cvs diff (tkdiff)\n$ cvs status\n$ cvs commit\n\nWe don't use branches.\nOur model is strict forward with a centralized, one main branch model to \navoid mistakes .\nWe see branches as evil ; some merges in Verilog codes means another 10+ \nhours of simulation and regression.\n\nI'm a verification engineers for the hardware chips designers, there we use \nVera and SystemVerilog which requires much in\ndepth use of SCM functions.  So, the choice of tools is much more important \non our side (the designers only checkin and out, diff, and minimal merging)\n\nI m frustrated about the situration, i truly want Git in ASIC world !!!\n(yell out loud... no p4, no svn, no clearcase... or i rather keep cvs)\n\nIs there a way to specify the use of a simple GIT model in config, or like, \ninfo/attribute,\nsuch that (in git main repository model of course) :\n\n(1) SHA1s are hidden, but replaced by simple numbers\n(2) Simple, incremental numbers (like 'git-5432' ; what we use \n'git-describe' to generate)\n(3) Reference of simple revision numbers in all git commands and tools like \ngitk, not SHA1\n\nI personally have no problem with the SHA1 . but many are allergic to it .\n\nAs I have learned so much about the power of git,\nI understand that:\n\n- 'git-show-branch' actually show reversed serialized version numbers (we \nwant it the other way, accending)\n- 'git-describe' gives you commit numbers since your last annotated tags ( \nie, git-5423-g7def45b)\n\nso, i understand that a simple numbering scheme can be done .\n\nI truly hope that the in the main repository model of git this can be turned \non by a switch or in the git config .\n\nIs it too complicated to incorporate this model ?\n\nI m eager to hear about the options\n\nThanks,\n\n  Justin Leung\n\n  ASIC Verification Engineering\n\n  Redback Networks\n  a company of Ericsson \n"},{"id":"76577","messageId":"B03D1DC3-7088-41AF-BB8B-9A696E7C5B8E@sb.org","threadId":"13471","inReplyTo":"BA7F9A3C7EDA4CDD99016093B0DB55C0@justinuTop","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-05-11T05:21:32Z","receivedAt":"2008-05-11T05:21:32Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On May 11, 2008, at 12:08 AM, Justin Leung wrote:\n\n> Hi all,\n>\n> * This email probably represent the whole hardware ASIC community  \n> about git *\n>\n> I'm evaluating Git as the replacement of CVS for the ASIC group in  \n> my company,\n> but things are moving along very bumpy.\n>\n> I (and many others doing the evaluation) love the tool dearly; we  \n> love the local repository and inter-db sync'ing .\n> I see a lot of potential in productivity and changes in work model  \n> that helps efficiency in ASIC dev.\n>\n> BUT, my managers, some veterans, and directors are EXTREMELY  \n> concerned about the ease-of-use..\n> so much that they are going to pick SVN !  uh-oh....i m serious =(\n>\n> Alot of people argued, why not SVN ? it's CVS++ and it's ease of use  \n> not a problem when comparing to Git.\n>\n> here are the things not fitting right in ASIC dev:\n>\n> - no incremental revision numbers (they are so scared of the 40hex  \n> SHA1)\n>\n> - Inability to reference without SHA1, they want simple numbering  \n> (ie, 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  \n> anything more than 4-5 digits)\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> Most RTL design veterans only use less then 5-6 cvs commands in  \n> their whole life (LOL, i m serious) :\n>\n> $ cvs checkout\n> $ cvs update\n> $ cvs log\n> $ cvs diff (tkdiff)\n> $ cvs status\n> $ cvs commit\n>\n> We don't use branches.\n> Our model is strict forward with a centralized, one main branch  \n> model to avoid mistakes .\n> We see branches as evil ; some merges in Verilog codes means another  \n> 10+ hours of simulation and regression.\n>\n> [snip]\n\nHonestly, it sounds like SVN is actually a good fit here. Just because  \ngit is awesome for many things does not mean it is the end-all-be-all  \nof version control systems. SVN still has its place as the last true  \ncentralized system. Given your constraints and workflow, why do you  \nthink git is better than SVN?\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"76581","messageId":"83EE186A7AF140179C6C73B367471EC7@justinuTop","threadId":"13471","inReplyTo":"B03D1DC3-7088-41AF-BB8B-9A696E7C5B8E@sb.org","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Justin Leung","fromEmail":"jleung@redback.com","sentAt":"2008-05-11T05:29:51Z","receivedAt":"2008-05-11T05:29:51Z","isPatch":false,"sender":{"key":"jleung@redback.com","avatar":null},"body":"Hi Kevin,\n\nThe ability of inter-user (designer-verifier) code sync'ing without letting \nthe incomplete or incompatible RTL code to propagate to the main build \nstream is going to facilitate the design flow and efficiency .\n\nThe ability of local revision control means that no more over writing of \ndesign files until commit .\n\nI think these 2 things will really buy us alot .\n\n Justin\n\n> Honestly, it sounds like SVN is actually a good fit here. Just because \n> git is awesome for many things does not mean it is the end-all-be-all  of \n> version control systems. SVN still has its place as the last true \n> centralized system. Given your constraints and workflow, why do you  think \n> git is better than SVN?\n>\n> -Kevin Ballard\n>\n> -- \n> Kevin Ballard\n> http://kevin.sb.org\n> kevin@sb.org\n> http://www.tildesoft.com\n>\n>\n> \n"},{"id":"76582","messageId":"F975216F-9B61-41FF-A7FE-3D7EF09D137B@sb.org","threadId":"13471","inReplyTo":"83EE186A7AF140179C6C73B367471EC7@justinuTop","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-05-11T05:33:48Z","receivedAt":"2008-05-11T05:33:48Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On May 11, 2008, at 12:29 AM, Justin Leung wrote:\n\n> Hi Kevin,\n>\n> The ability of inter-user (designer-verifier) code sync'ing without  \n> letting the incomplete or incompatible RTL code to propagate to the  \n> main build stream is going to facilitate the design flow and  \n> efficiency .\n>\n> The ability of local revision control means that no more over  \n> writing of design files until commit .\n>\n> I think these 2 things will really buy us alot .\n>\n> Justin\n>\n>> Honestly, it sounds like SVN is actually a good fit here. Just  \n>> because git is awesome for many things does not mean it is the end- \n>> all-be-all  of version control systems. SVN still has its place as  \n>> the last true centralized system. Given your constraints and  \n>> workflow, why do you  think git is better than SVN?\n>>\n>> -Kevin Ballard\n\nBut they come at an expense - no more linear revision numbers, more  \ncomplex commands, etc. You can't have it both ways.\n\nYou could always use a main SVN repo and then use git-svn to maintain  \nyour own private git repos, do all the code syncing you want there,  \nand then push it back to SVN when you want to send it back to the main  \nbuild stream. If you go this route, be careful to maintain a linear  \nhistory on the branch that tracks the SVN repo, as SVN cannot handle  \nmerges the way git can. You'll want to either do rebasing or squashed  \nmerges (to avoid multiple parents).\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"76595","messageId":"46d6db660805110221y1207974dt3be709e1b67cf3d6@mail.gmail.com","threadId":"13471","inReplyTo":"BA7F9A3C7EDA4CDD99016093B0DB55C0@justinuTop","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2008-05-11T09:21:57Z","receivedAt":"2008-05-11T09:21:57Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On Sun, May 11, 2008 at 7:08 AM, Justin Leung <jleung@redback.com> wrote:\n> Hi all,\n>\n> * This email probably represent the whole hardware ASIC community about git\n> *\n\nI'm an ASIC designer too.\n\n> here are the things not fitting right in ASIC dev:\n>\n> - no incremental revision numbers (they are so scared of the 40hex SHA1)\n\nthis is unimportant: if they want to track a specific release of a\nfile, it's better to look at what was the file's content from this cut\nto that cut.\n\n>\n> - Inability to reference without SHA1, they want simple numbering (ie,\n> version 100, 120, 120.1, 130.4.5)\n\nthis is where tags and branches are useful to point to a specific release/cut.\n\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\nsame answer\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\njust use gitk and git-gui: almost all can be done with these two\ngraphical tools.\n\n>\n> Most hardware chip designers were using CVS since their first job.\n> It suited the purpose very well.\n\nfor linear development, yes. but when we were requested to perform\nmaintenance on a specific old cut, this was becoming a nightmare.\n\n>\n> Most RTL design veterans only use less then 5-6 cvs commands in their whole\n> life (LOL, i m serious) :\n>\n> $ cvs checkout\n> $ cvs update\n> $ cvs log\n> $ cvs diff (tkdiff)\n> $ cvs status\n> $ cvs commit\n\ngitk, git-gui: two commands (actually gitk can be called from git-gui)\n\n>\n> We don't use branches.\n\nthis is the wrong approach.\n\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\nuse branches to reference the different ressources (rtl, simulation, layout).\nthen track these branches between them for deliveries and work/flow.\n\nuse tags to mark specific releases/cuts.\n\n> - 'git-show-branch' actually show reversed serialized version numbers (we\n> want it the other way, accending)\n\nyou can create an alias: git-show-branch | tail -r\n\n> - 'git-describe' gives you commit numbers since your last annotated tags (\n> ie, git-5423-g7def45b)\n>\n> so, i understand that a simple numbering scheme can be done .\n\nyes, I used to be scared by sha1 too: I even created numbered tags for\neach commit. Until I read more about git, and stopped expecting using\ngit as svn/cvs.\n\n>\n> I truly hope that the in the main repository model of git this can be turned\n> on by a switch or in the git config .\n\nno, it would kill the right approach: embrace the index, and never look back.\n\n>\n> Is it too complicated to incorporate this model ?\n\nyou have to adapt your methods instead: trust another ASIC designer :-)\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !\n"},{"id":"76596","messageId":"m363tl5h41.fsf@localhost.localdomain","threadId":"13471","inReplyTo":"BA7F9A3C7EDA4CDD99016093B0DB55C0@justinuTop","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-11T09:23:54Z","receivedAt":"2008-05-11T09:23:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Justin Leung\" <jleung@redback.com> writes:\n\n> Hi all,\n> \n> * This email probably represent the whole hardware ASIC community\n>   about git *\n> \n> I'm evaluating Git as the replacement of CVS for the ASIC group in\n> my company, but things are moving along very bumpy.\n> \n> I (and many others doing the evaluation) love the tool dearly; we\n> love the local repository and inter-db sync'ing .  I see a lot of\n> potential in productivity and changes in work model that helps\n> efficiency in ASIC dev.\n\nPlease note that Git is not the only OSS DVCS.  There is Mercurial,\nwhich has repute of being easy to use (in my opinion: at least for\nmainly linear development), and there is Bazaar (formerly Bazaar-NG).\nBoth are mature products.\n\nIMHO the main strength of Git (besides performance, but now I think it\nis less of an edge, especially for not very large projects) is deling\nwith nonlinear history and branch-based (topic  branches) development.\nIf that is the worth paying essential complexness (as opposed to\naccidental complexness, which unfortunately Git also has some) for...\n\n> BUT, my managers, some veterans, and directors are EXTREMELY\n> concerned about the ease-of-use..  so much that they are going to\n> pick SVN !  uh-oh....i m serious =(\n> \n> Alot of people argued, why not SVN ? it's CVS++ and it's ease of use\n> not a problem when comparing to Git.\n\nPerhaps Subversion is the right tool for you.\n\n> Here are the things not fitting right in ASIC dev:\n> \n> - no incremental revision numbers (they are so scared of the 40hex SHA1)\n\nIncremental revision numbers _require_ single, central authority\nassigning them.  You cannot have simple revision numbers in truly\ndistributed development.\n\nBoth Mercurial and Bazaar allow to use incremental revsision numbers,\nat least for revisions (commits) along trunk (mainline).  Note that\nrevision numbers are either local to repository (Mercurial, Bazaar),\nor require treating one of repository as special, i.e. use different\ncommands for central repository from commands used when merging in\nother repositories (Bazaar).\n\n> - Inability to reference without SHA1, they want simple numbering (ie,\n> version 100, 120, 120.1, 130.4.5)\n\nYou can tag, and use git-describe output, i.e. v1.4.2, or\nv1.5.5.1-182-g7480b28.  Or you can use transitional \"reverse\"\nnumbering, counting from latest revision, like HEAD^, master~10,\nor master@{2} (the last has only local meaning, and only if reflogs\nare enabled which is now default).\n\n> - Inability to refer to a file by a simple number\n\nErrr... refer to _file_ by a number? Why not a pathname, or revision\nand pathname (<rev>:<path> format)?\n\n> (the backend guys will be confused by SHA1; they can't work with\n> anything more than 4-5 digits)\n\nYou can use shortened sha1, usually 7 characters... but I think this\nis an artificial fear.  When using git you almost never have to use\neither SHA1, or shortened SHA1 identifier.\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\nNow that Cogito is unmaintained, you can try EasyGit (eg) or Pyrite,\nalthough AFAIK both are in early development stages.  And there is\nalso git-gui and other commit tools there...\n\n> Most hardware chip designers were using CVS since their first job.\n> It suited the purpose very well.\n\nAnd is probably responsible for some SCM bad habits...\n\n> Most RTL design veterans only use less then 5-6 cvs commands in their\n> whole life (LOL, i m serious)\n[...]\n> We don't use branches.\n\nBad habit!\n\nProbably because branching in CVS was very complicated, error prone,\nand just plain uncomfortable to use (sticky tags, blehhh...).\n\nSubversion makes it easy to branch, but developers forgot to make it\neasy to merge (this is to be corrected in upcoming 1.5 release, and\nyou can migitate it using third party tools / extensions like svnmerge\nor SVK; the last also gives replicability, and beginnings of\ndistributed development).\n\n> Our model is strict forward with a centralized, one main branch model\n> to avoid mistakes .\n> We see branches as evil ; some merges in Verilog codes means another\n> 10+ hours of simulation and regression.\n\nBad habit!\n\nBranches are there to not stomp on each other changes when deveoping\nindependent features.  They are also a must have if you plan to\nmaintain fixes to old releases.\n\nWhen merging is easy it allows you to merge early, or do a try merge,\nand fix conflict early, when they are easy to spot and resolve.\n\nPlease watch Linus Torvalds opinionated Google Tech Talk on Git:\n  http://www.youtube.com/watch?v=4XpnKHJAok8\n  http://git.or.cz/gitwiki/LinusTalk200705Transcript\n\n> I'm a verification engineers for the hardware chips designers, there\n> we use Vera and SystemVerilog which requires much in\n> depth use of SCM functions.  So, the choice of tools is much more\n> important on our side (the designers only checkin and out, diff, and\n> minimal merging)\n\nCould you elaborate? What SCM functions do you need?\n\n> I m frustrated about the situration, i truly want Git in ASIC world !!!\n> (yell out loud... no p4, no svn, no clearcase... or i rather keep cvs)\n\nSubversion _is_ improvement on CVS, some brain damages of it aside (as\nfor example lack of _unchangeable_ tags; and no, unchangeable by\nconvention doesn't count).  You can use git-svn to interact with it.\n \n> Is there a way to specify the use of a simple GIT model in config,\n> or like, info/attribute, such that (in git main repository model of\n> course):\n> \n> (1) SHA1s are hidden, but replaced by simple numbers\n> (2) Simple, incremental numbers (like 'git-5432' ; what we use\n> 'git-describe' to generate)\n> (3) Reference of simple revision numbers in all git commands and tools\n> like gitk, not SHA1\n\nI think you can get it by heavy use of tags from within hooks, even\nwithout changes to git core, and without using any wrapper /\nporcelain.  But this might affect performance.\n\nNote (again) that \"simple numbers\" for revision names are possible\n_only_ in centralized development, with centralized authority\nassigning those incremental numbers (\"monitor\" in parallell\ncomputing).\n\n> I personally have no problem with the SHA1 . but many are allergic to it .\n\nAgain: in my use of git I almost never need to use SHA1, or shorthened\nSHA1, even for copy'n'paste.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"76676","messageId":"56b7f5510805112257u13252c71kda880fb3f3e43485@mail.gmail.com","threadId":"13471","inReplyTo":"83EE186A7AF140179C6C73B367471EC7@justinuTop","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2008-05-12T05:57:01Z","receivedAt":"2008-05-12T05:57:01Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Sat, May 10, 2008 at 10:29 PM, Justin Leung <jleung@redback.com> wrote:\n> > Honestly, it sounds like SVN is actually a good fit here. Just because git\n> > is awesome for many things does not mean it is the end-all-be-all  of\n> > version control systems. SVN still has its place as the last true\n> > centralized system. Given your constraints and workflow, why do you  think\n> > git is better than SVN?\n>\n> The ability of inter-user (designer-verifier) code sync'ing without letting\n> the incomplete or incompatible RTL code to propagate to the main build\n> stream is going to facilitate the design flow and efficiency .\n>\n> The ability of local revision control means that no more over writing of\n> design files until commit .\n>\n> I think these 2 things will really buy us alot .\n\nHi Justin,\n\nI was originally drawn to git for the exact reasons you identified in\nyour 2nd email.\nNamely,  it is extremely difficult in a p4-based environment to share\nintermediate work within a design team without pushing the work out to\nbe visible by the entire team.  \"Inter-user design sync'ing\" is exactly what\nI wanted.  In its absence,  we have made all references between files\nrelative.  This means you can flip over to someone else's netlist by changing\none path (say to the top-level design file) to point into someone's private\nrepository.  That top-level file then includes everything else using paths\nrelative to its own location,  so you get the correct stuff automatically.\nOf course,  you get tripped up all the time by stuff implicitly used and not\nnamed in the top-level file and its children...\n\nNow,  it would be far better for this to be a lightweight branch in git,  and\nthen having people checkout this branch and use it.  (Because,  for example,\nwhile one person is pointing into another's tree,  the latter can't change.)\nBut p4 (and cvs) has trained everyone to think of branches as painful and\nfor wizards only.  Plus I am not personally interested in investing any time\nwriting scripts on top of p4;  the ideas I outlined in the previous paragraph\nwere easier and almost as good as anything (easily) doable in p4\n(but not as good as lightweight branching).\n\nI agree with other responses to your email that you may want to think\nabout writing simple wrapper scripts that add tags to checkins with some\nsimple incrementing numeric part to keep your back-end people happy.  Yet\nother responses were distracted by the linearity of your centralized/shared\ncheckins:  the inter-design sync'ing you want,  and the lightweight branching\nit may imply,  aren't necessarily incompatible with the linear main\npublic history\nthat most design teams expect (and which is unavoidable in design work\ncontaining lots of unmergeable files,  such as layout design).\nSo I don't necessarily think you would be happy with Subversion\n(I'm certainly not happy with p4).\n\nThere are two other issues you may want to keep in mind.  In our\nchip design activities,  we have a lot of very large files (100MB to ~3GB),\nand the p4 repository has grown beyond 3TB.  Now,  this is simply\na data set size region which is not used by the git developers.  I think\nthe git data model is fine for large projects and files (Linus mused otherwise\na few weeks ago,  but it seems fine to me),  but due to lack of use,\nvarious details when handling large files/projects remain to be worked out\nand/or optimized as much as the rest of git.  It is true since I\nstarted watching\nthere have been a lot of important improvements in this area.\n\nSecondly,  you may also want to discuss with your IT people (or whoever\nis responsible for back-up) how git packs/repacks repositories.  Ours were\nvery uncomfortable with the idea that the _entire_ repository has to get\nre-arranged frequently.  I think they would have been much happier\nwith an approach more similar to how Unix systems were backed up in the\n80s: have a level-0 repack which repacks everything, a level-1 which repacks\nonly stuff added since the last level-0,  level-2 since level-1,  etc.\nTo do this would be a pretty straightforward change to git-repack.sh,\nprobably using .keep files.  In each level it is clear what needs to\nbe backed up.\n\nAnyway,  good luck!  Many of the things you touched on,  or which I\nmentioned above,  have been (partially) implemented or at least\ndiscussed before,\nso your requests aren't crazy.  Unfortunately,  in my case,  having 6 surgeries\nin my family in the last year has kept me from doing that much useful\nfor git along these lines and thus I remain stuck with p4 for now.\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"76745","messageId":"4828904B.6080708@redback.com","threadId":"13471","inReplyTo":"F975216F-9B61-41FF-A7FE-3D7EF09D137B@sb.org","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Justin Leung","fromEmail":"jleung@redback.com","sentAt":"2008-05-12T18:45:31Z","receivedAt":"2008-05-12T18:45:31Z","isPatch":false,"sender":{"key":"jleung@redback.com","avatar":null},"body":"\nThanks Kevin,\n\n   I think i better give svn another serious look . \n\nbut then, my impression from the rest of the people is that p4 and svn \nare not the ultimate tools for hardware development either .\n\nI guess we just do not have the perfect tool for asic dev yet .\n\n Justin\n\nKevin Ballard wrote:\n> But they come at an expense - no more linear revision numbers, more \n> complex commands, etc. You can't have it both ways.\n>\n> You could always use a main SVN repo and then use git-svn to maintain \n> your own private git repos, do all the code syncing you want there, \n> and then push it back to SVN when you want to send it back to the main \n> build stream. If you go this route, be careful to maintain a linear \n> history on the branch that tracks the SVN repo, as SVN cannot handle \n> merges the way git can. You'll want to either do rebasing or squashed \n> merges (to avoid multiple parents).\n>\n> -Kevin Ballard\n"},{"id":"76746","messageId":"482891C6.1050607@redback.com","threadId":"13471","inReplyTo":"46d6db660805110221y1207974dt3be709e1b67cf3d6@mail.gmail.com","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Justin Leung","fromEmail":"jleung@redback.com","sentAt":"2008-05-12T18:51:50Z","receivedAt":"2008-05-12T18:51:50Z","isPatch":false,"sender":{"key":"jleung@redback.com","avatar":null},"body":"\nHi Christian,\n\n I personally have no problem dealing without revision numbers .\nI merely used them directly .\n\nHowever, I think I gotta admit that this is a world more than just us .\n\nThere's an obvious reason why Windows and MS are still standing, and IE \nis still the market holder :\n\nwe are the minority ..  a lot of people just care to get the work done .\n\nsurely i felt defeated, but one lesson to know is that the interface is \nvery important for beginners ;\n\nand a simplified numbering scheme is really what the managers/VPs are \nlooking for to avoid rookie mistakes .\n\nThanks for the support tho =)\nI know i m not alone\n\n Justin\n\nChristian MICHON wrote:\n> I'm an ASIC designer too.\n> this is unimportant: if they want to track a specific release of a\n> file, it's better to look at what was the file's content from this cut\n> to that cut.\n> just use gitk and git-gui: almost all can be done with these two\n> graphical tools.\n>\n> for linear development, yes. but when we were requested to perform\n> maintenance on a specific old cut, this was becoming a nightmare.\n> gitk, git-gui: two commands (actually gitk can be called from git-gui)\n> this is the wrong approach.\n> use branches to reference the different ressources (rtl, simulation, layout).\n> then track these branches between them for deliveries and work/flow.\n>\n> use tags to mark specific releases/cuts.\n> you can create an alias: git-show-branch | tail -r\n>   \n>\n> yes, I used to be scared by sha1 too: I even created numbered tags for\n> each commit. Until I read more about git, and stopped expecting using\n> git as svn/cvs.\n>   \n> no, it would kill the right approach: embrace the index, and never look back.\n>   \n>\n> you have to adapt your methods instead: trust another ASIC designer :-)\n>   \n"},{"id":"76752","messageId":"4828942E.2060803@redback.com","threadId":"13471","inReplyTo":"56b7f5510805112257u13252c71kda880fb3f3e43485@mail.gmail.com","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Justin Leung","fromEmail":"jleung@redback.com","sentAt":"2008-05-12T19:02:06Z","receivedAt":"2008-05-12T19:02:06Z","isPatch":false,"sender":{"key":"jleung@redback.com","avatar":null},"body":"\nHi Dana,\n\n My best wishes to your family . having 6 surgeries is no joke.\nI wish you have all recovered well .\n\nThanks for letting me know that I am not the crazy one to try to \nimplement git in asia :)\n\nI believe that this tool is full of potential in our community.\nAll it takes would be just a minor tweak to fit our methodology .\n\nin the mean time, while my team is still happy with cvs ,\ndue to the design habits (good or bads.. but they are used to the way it \nis ) ,\nprobably svn and p4 are still the only logical choose ;\nnot that I m happy with these chooses though.\n\ngit will get there but i think no big hardware firm would like to be the \nfirst to adopt to it ..\nespecially my managements would like to minimize risks .\n\n\n Justin\n\n\nDana How wrote:\n> Hi Justin,\n>\n> I was originally drawn to git for the exact reasons you identified in\n> your 2nd email.\n> Namely,  it is extremely difficult in a p4-based environment to share\n> intermediate work within a design team without pushing the work out to\n> be visible by the entire team.  \"Inter-user design sync'ing\" is exactly what\n> I wanted.  In its absence,  we have made all references between files\n> relative.  This means you can flip over to someone else's netlist by changing\n> one path (say to the top-level design file) to point into someone's private\n> repository.  That top-level file then includes everything else using paths\n> relative to its own location,  so you get the correct stuff automatically.\n> Of course,  you get tripped up all the time by stuff implicitly used and not\n> named in the top-level file and its children...\n>\n> Now,  it would be far better for this to be a lightweight branch in git,  and\n> then having people checkout this branch and use it.  (Because,  for example,\n> while one person is pointing into another's tree,  the latter can't change.)\n> But p4 (and cvs) has trained everyone to think of branches as painful and\n> for wizards only.  Plus I am not personally interested in investing any time\n> writing scripts on top of p4;  the ideas I outlined in the previous paragraph\n> were easier and almost as good as anything (easily) doable in p4\n> (but not as good as lightweight branching).\n>\n> I agree with other responses to your email that you may want to think\n> about writing simple wrapper scripts that add tags to checkins with some\n> simple incrementing numeric part to keep your back-end people happy.  Yet\n> other responses were distracted by the linearity of your centralized/shared\n> checkins:  the inter-design sync'ing you want,  and the lightweight branching\n> it may imply,  aren't necessarily incompatible with the linear main\n> public history\n> that most design teams expect (and which is unavoidable in design work\n> containing lots of unmergeable files,  such as layout design).\n> So I don't necessarily think you would be happy with Subversion\n> (I'm certainly not happy with p4).\n>\n> There are two other issues you may want to keep in mind.  In our\n> chip design activities,  we have a lot of very large files (100MB to ~3GB),\n> and the p4 repository has grown beyond 3TB.  Now,  this is simply\n> a data set size region which is not used by the git developers.  I think\n> the git data model is fine for large projects and files (Linus mused otherwise\n> a few weeks ago,  but it seems fine to me),  but due to lack of use,\n> various details when handling large files/projects remain to be worked out\n> and/or optimized as much as the rest of git.  It is true since I\n> started watching\n> there have been a lot of important improvements in this area.\n>\n> Secondly,  you may also want to discuss with your IT people (or whoever\n> is responsible for back-up) how git packs/repacks repositories.  Ours were\n> very uncomfortable with the idea that the _entire_ repository has to get\n> re-arranged frequently.  I think they would have been much happier\n> with an approach more similar to how Unix systems were backed up in the\n> 80s: have a level-0 repack which repacks everything, a level-1 which repacks\n> only stuff added since the last level-0,  level-2 since level-1,  etc.\n> To do this would be a pretty straightforward change to git-repack.sh,\n> probably using .keep files.  In each level it is clear what needs to\n> be backed up.\n>\n> Anyway,  good luck!  Many of the things you touched on,  or which I\n> mentioned above,  have been (partially) implemented or at least\n> discussed before,\n> so your requests aren't crazy.  Unfortunately,  in my case,  having 6 surgeries\n> in my family in the last year has kept me from doing that much useful\n> for git along these lines and thus I remain stuck with p4 for now.\n>   \n"},{"id":"76806","messageId":"alpine.LNX.1.00.0805121733530.19665@iabervon.org","threadId":"13471","inReplyTo":"BA7F9A3C7EDA4CDD99016093B0DB55C0@justinuTop","subject":"Re: Verilog/ASIC development support is insufficient in git , help!","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-12T23:09:07Z","receivedAt":"2008-05-12T23:09:07Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 10 May 2008, Justin Leung wrote:\n\n> Hi all,\n> \n> * This email probably represent the whole hardware ASIC community about git *\n> \n> I'm evaluating Git as the replacement of CVS for the ASIC group in my company,\n> but things are moving along very bumpy.\n> \n> I (and many others doing the evaluation) love the tool dearly; we love the\n> local repository and inter-db sync'ing .\n> I see a lot of potential in productivity and changes in work model that helps\n> efficiency in ASIC dev.\n> \n> BUT, my managers, some veterans, and directors are EXTREMELY concerned about\n> the ease-of-use..\n> so much that they are going to pick SVN !  uh-oh....i m serious =(\n> \n> Alot of people argued, why not SVN ? it's CVS++ and it's ease of use not a\n> problem when comparing to Git.\n\nAs far as I can tell, wherever SVN is more powerful than CVS, it is \ncomplicated to use. I think that, if all you want if to rename files and \ndirectories, you could use SVN. Otherwise, the way SVN implements advanced \nfeatures is more confusing than git.\n\n> here are the things not fitting right in ASIC dev:\n> \n> - no incremental revision numbers (they are so scared of the 40hex SHA1)\n\nThis is pretty much forced by being able to trade changes without going \nthrough the central repo combined with the desire to have stable \nidentifiers. If I can get from you a version after the fifth version in \nthe central repo and before the sixth version there, what number is the \nrevision I got?\n\nOn the other hand, we should be able to make the sequence of latest \ncommits on the central site be marked with numbers in increasing order. \nThis is slightly different from a linear order (there will be commits \nwithout numbers, for example, if a developer does a series of commits and \nthen sends in a batch, or does some commits and a merge; only the ends of \nthese sets get numbers).\n\n> - Inability to reference without SHA1, they want simple numbering (ie, version\n> 100, 120, 120.1, 130.4.5)\n\nWhenever you have an important state, you can tag it with a number. Not \neverything gets numbered that way, but the other things aren't so \ninteresting for people working at that level anyway.\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 more\n> than 4-5 digits)\n\nI think you'd only want to send the backend guys commits that you'd tag \nwith version numbers.\n\n> - Complexity of commands (although we can have warpper, but real git commands\n> 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> Most RTL design veterans only use less then 5-6 cvs commands in their whole\n> life (LOL, i m serious) :\n> \n> $ cvs checkout\n> $ cvs update\n> $ cvs log\n> $ cvs diff (tkdiff)\n> $ cvs status\n> $ cvs commit\n\n$ git clone / git checkout\n$ git pull\n$ git log\n$ git diff\n$ git status\n$ git commit -a\n$ git push\n\nThe main training is:\n\n - type \"git\" instead of \"cvs\"\n - to get a new working directory, you use \"clone\" (but to revert a \n   working directory file to the committed state, you still use \n   \"checkout\")\n - \"update\" is \"pull\"\n - use \"-a\" with \"commit\", unless you're committing only a limited set of \n   paths\n - after \"commit\", check whether what you did was right, and then do \"git \n   push\" to publish your changes\n\n> We don't use branches.\n> Our model is strict forward with a centralized, one main branch model to avoid\n> mistakes .\n\nThere are multiple things that branches do.\n\n - The first is that, whenever you have different revisions in different \n   places, they're always different branches in some sense. That is, \n   there's a \"latest state of the project\" as checked into the central \n   server, but also a yet-newer state that's each person's working \n   directory contents, and often a trailing state that's the central \n   server state as of the last time the person updated. Each of these is \n   tracked even in CVS, but in CVS they're implicit and qualitatively \n   different, while in git they're explicit and mostly stored the same \n   way.\n\n - The second is that there can be multiple lines of development in the \n   central location, such that there's a latest checked-in-and-published \n   state for each that's different. This is explicit in CVS, and doesn't \n   work very well, and is also available in git and is much nicer. But, in \n   either case, you don't need to use it. (In fact, git's own development \n   barely uses it, and only for bugfixes to older versions while the \n   current version is under development; aside from that, all of the \n   branches in git development are of other types.)\n\n - In git, in addition to having a \"last seen state of mainline\" branch, \n   you can have \"last seen states\" of other developers' working \n   directories. And you can have branches as ways of putting changes out \n   for other developers to get without the main branch getting them. For \n   example, Junio's \"next\" branch is all essentially previews of stuff he \n   might commit to the mainline. This is fundamentally just a unified \n   tracking mechanism for the ability to do developer-to-developer \n   transfers of state. This doesn't need to be any more (or less) visible \n   to project managers than the contents of people's CVS working \n   directories are (that is, it'll let them know how close the developers \n   are to having a version they can get into the mainline).\n\n - in git, you can use branches to work on multiple different changes \n   without having multiple working directories. This is, again, a private \n   matter for the developer, and entirely optional.\n\n> We see branches as evil ; some merges in Verilog codes means another 10+ hours\n> of simulation and regression.\n\nWell, you'd also have the same 10+ hours in order to retest your changes \nafter a \"cvs update\" if somebody else commits while you're working on \nsomething. A merge in the git sense is essentially the same thing, except \nthat you can have multiple committed states on the local side, and it \nunderstands if the same change reaches the mainline by multiple routes \nbecause people exchanged work directly.\n\nOn ther other hand, you can use \"git rebase\" and it works almost exactly \nlike \"cvs update\" except that you've saved the changes that are from your \nlocal working directory so that, if you mess up resolving conflicts, you \ncan abort and try again.\n\n> I'm a verification engineers for the hardware chips designers, there we use\n> Vera and SystemVerilog which requires much in\n> depth use of SCM functions.  So, the choice of tools is much more important on\n> our side (the designers only checkin and out, diff, and minimal merging)\n>\n> I m frustrated about the situration, i truly want Git in ASIC world !!!\n> (yell out loud... no p4, no svn, no clearcase... or i rather keep cvs)\n> \n> Is there a way to specify the use of a simple GIT model in config, or like,\n> info/attribute,\n> such that (in git main repository model of course) :\n> \n> (1) SHA1s are hidden, but replaced by simple numbers\n> (2) Simple, incremental numbers (like 'git-5432' ; what we use 'git-describe'\n> to generate)\n> (3) Reference of simple revision numbers in all git commands and tools like\n> gitk, not SHA1\n\nIf you have a post-update hook on the central repo that makes a tag of the \nform \"r<number>\", with <number> counting up, that'll pretty much do it. \nBut there will be other commits that don't get tagged because they were \nalready historical when they reached the central server. But people \ngenerally don't have to care about those unless they're already interested \nin doing something complicated.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}