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