Hi Dana,
My best wishes to your family . having 6 surgeries is no joke.
I wish you have all recovered well .
Thanks for letting me know that I am not the crazy one to try to
implement git in asia :)
I believe that this tool is full of potential in our community.
All it takes would be just a minor tweak to fit our methodology .
in the mean time, while my team is still happy with cvs ,
due to the design habits (good or bads.. but they are used to the way it
is ) ,
probably svn and p4 are still the only logical choose ;
not that I m happy with these chooses though.
git will get there but i think no big hardware firm would like to be the
first to adopt to it ..
especially my managements would like to minimize risks .
Justin
Dana How wrote:
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
