Re: Verilog/ASIC development support is insufficient in git , help!

> Hi Justin,
>
> I was originally drawn to git for the exact reasons you identified in
> your 2nd email.
> Namely,  it is extremely difficult in a p4-based environment to share
> intermediate work within a design team without pushing the work out to
> be visible by the entire team.  "Inter-user design sync'ing" is exactly what
> I wanted.  In its absence,  we have made all references between files
> relative.  This means you can flip over to someone else's netlist by changing
> one path (say to the top-level design file) to point into someone's private
> repository.  That top-level file then includes everything else using paths
> relative to its own location,  so you get the correct stuff automatically.
> Of course,  you get tripped up all the time by stuff implicitly used and not
> named in the top-level file and its children...
>
> Now,  it would be far better for this to be a lightweight branch in git,  and
> then having people checkout this branch and use it.  (Because,  for example,
> while one person is pointing into another's tree,  the latter can't change.)
> But p4 (and cvs) has trained everyone to think of branches as painful and
> for wizards only.  Plus I am not personally interested in investing any time
> writing scripts on top of p4;  the ideas I outlined in the previous paragraph
> were easier and almost as good as anything (easily) doable in p4
> (but not as good as lightweight branching).
>
> I agree with other responses to your email that you may want to think
> about writing simple wrapper scripts that add tags to checkins with some
> simple incrementing numeric part to keep your back-end people happy.  Yet
> other responses were distracted by the linearity of your centralized/shared
> checkins:  the inter-design sync'ing you want,  and the lightweight branching
> it may imply,  aren't necessarily incompatible with the linear main
> public history
> that most design teams expect (and which is unavoidable in design work
> containing lots of unmergeable files,  such as layout design).
> So I don't necessarily think you would be happy with Subversion
> (I'm certainly not happy with p4).
>
> There are two other issues you may want to keep in mind.  In our
> chip design activities,  we have a lot of very large files (100MB to ~3GB),
> and the p4 repository has grown beyond 3TB.  Now,  this is simply
> a data set size region which is not used by the git developers.  I think
> the git data model is fine for large projects and files (Linus mused otherwise
> a few weeks ago,  but it seems fine to me),  but due to lack of use,
> various details when handling large files/projects remain to be worked out
> and/or optimized as much as the rest of git.  It is true since I
> started watching
> there have been a lot of important improvements in this area.
>
> Secondly,  you may also want to discuss with your IT people (or whoever
> is responsible for back-up) how git packs/repacks repositories.  Ours were
> very uncomfortable with the idea that the _entire_ repository has to get
> re-arranged frequently.  I think they would have been much happier
> with an approach more similar to how Unix systems were backed up in the
> 80s: have a level-0 repack which repacks everything, a level-1 which repacks
> only stuff added since the last level-0,  level-2 since level-1,  etc.
> To do this would be a pretty straightforward change to git-repack.sh,
> probably using .keep files.  In each level it is clear what needs to
> be backed up.
>
> Anyway,  good luck!  Many of the things you touched on,  or which I
> mentioned above,  have been (partially) implemented or at least
> discussed before,
> so your requests aren't crazy.  Unfortunately,  in my case,  having 6 surgeries
> in my family in the last year has kept me from doing that much useful
> for git along these lines and thus I remain stuck with p4 for now.
>