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:
quoted text
>> - 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html