slash-some_notes_about_using_cvs

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



by RGRistroph on Tuesday May 28, @12:18PM (Score:1) (#3596903)
   (User #86936 Info) http://www.geocities.com/rgristroph [ Neutral ]
   
   The reason why tracking directory changes isn't in there is that most
   projects don't need that. By the time a project does need it, the
   developers have been using CVS for a while, and think according to
   it's limitations, and arrange their projects accordingly.
   The question is, what features of CVS were considered lacking for this
   particular project, i.e., the linux kernel ?

   Parenthetically, I'd like to note that in my (limited) experience,
   people who resist CVS usually just don't want to learn the new tool
   and see it as interfering in their normal work by making them type
   bureaucratic commands before editting files (not true, this is a false
   perception derived from other version management systems) or they just
   don't want to really collaborate at all, and the objections to CVS are
   a way to say "I really don't want to work that closely with you."
   Obviously the last case doesn't apply to Linus :)

   We can also be confident Linus is not rejecting CVS from a position of
   ignorance. Go to groups.google.com and do the search on "author:Linus
   author:Torvalds cvs" and you can see his comments on the subject; he
   describes using CVS for work, and specific objections such as the ease
   of finding changes related only to a specific set of committs, stuff
   about branching, etc.
  
   However, in the limited search through the usenet postings I've done,
   I didn't see him ask for a feature that simply can't be done with CVS.
   Those things are complecated, and you might end up writing a little
   bash alias/function to automatically construct some of the weirder   
   commands, but they are not impossible; I'm an idiot and I've figured  
   out how do keep multiple branches and merge a successful one back into
   the main tree. You just print out the big manual/guide by Pers
   Cederqvist and read the first 20 to 30 pages to get started, and after
   that look things up.

   There is one thing that you do need to think about beforehand, and
   that is a scheme for branch naming and tagging (which are different
   things). If you have some type of system by which you give an easy to
   figure out tag to the point where you start a branch it makes it
   easier to go to the end of the branch and get a diff against the root
   of that branch, thus seeing all changes associated with that branch.
   People who use CVS for big things can describe their schemes.
   The one issue which I am not sure about CVS handling, is keeping
   multiple respositories on different machines and synching between them
   in a truly distributed fasion. If it's possible it would consist of
   some kludge like putting the kernel CVS repository under CVS control
   in a separate repository. But I am not entirely sure that is something
   you want to do in CVS anyway. If I wanted to hack on a code base for
   an extented period while away from net connectivity to the repository,
   I would copy the repository to my machine, disconnect and hack away.
   If I did minor changes and never needed to commit to my local copy,
   upon re-connecting I would point my working directory back at the real
   repository (this consists of running a little recursive perl script
   that edits the right places in all the CVS/Root and CVS/Repository
   files, lots of people have had to do this and you can find different
   tools to do that) and updating and committing. If I made a series of
   commits while away, and new branchs and etc, then it would be
   complecated and you would end up with various perl scripts wrapping
   around lots of getting stuff from various tags in one repository and
   committing to the other, a real pain. Those scripts would essentially
   add those functionalities to CVS, maybe even more difficult than
   putting it into CVS directly.

   But the point is it is possible. And if someone of Linus's stature
   asks for something in CVS, he's likely to get it. So I'm still
   disappointed in the current state of affairs. However, I am sure that
   many free software advocates are embarassed by the uproar and what it
   implies about the current state of CVS, and like me, are poking
   through the old posts to see what needs to be fixed or enhanced. The
   end result of all this will be good.
      
===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu