Talk:Concurrent Versions System

From Wikipedia, the free encyclopedia

Contents

[edit] CVS Status "ambiguity"

I don't think there's any "ambiguity" about CVS's status at all. Everyone knows its history and its current development, and neither of those involve the FSF except as a resource. It's not a GNU project, period. Anything on the GNU site that seems to indicate otherwise is simply mistaken. --LDC

Well, you'd have to define "GNU project" then. Do the programmers have to be paid by FSF? After all, FSF seems to own copyrights to parts of CVS. AxelBoldt

It gets rather confused at times. I worked on Gnucash, the GNOME accounting app, for a while. The copyright of the package is like Linux - it's GPL, and the copyright is owned by the individual authors, of whom there are quite a few. We discussed assigning the lot to the FSF, but we never got around to it. The project's web page, mailing list, and CVS archive was hosted on one of the developer's boxes. Given all that, I assumed that we weren't an "official" GNU project, and said so on the ML when somebody asked. I promptly got corrected by the original developer, who said RMS considered us so and mailed him privately on various issues on occasions. We shrugged and got back to work, and it makes no practical difference as far as we are concerned. --Robert Merkel

I suspect this is the case with CVS as well: Stallman simply claimed it as a GNU project without asking the devlopers what they think, and without the FSF having had anything to do with its creation or maintenance. --LDC

That is a bit too strong, I think. Jim Blandy was one of the founders of (now defunct) Cyclic Software, which maintained CVS for a long time. He then became one of the maintainers of GNU Guile -- which is incontrovertibly a GNU project. Anyway, even though the FSF may not directly do anything, if the developers say it's GNU, then it's GNU. --Hari

During the recent move of CVS development from cvshome.org to savannah.nongnu.org, the CVS team was officially informed that they are not considered a GNU project by the FSF, despite the FSF holding some of the copyrights and despite RMS sometimes asking for development favors (I had asked directly before about CVS's status without receiving a response). I think most of the pages on gnu.org have been corrected to reflect this. I updated the article accordingly.

Is there any reason not to archive this discussion?

Derek Price

[edit] Articled Moved to Lower-case Version and Back

It appears that this article was moved here from Concurrent Versions System a few weeks back. However, the article text indicates that the name should be capitalized. If there are no objections, I'll move it back shortly. Bryan 07:59, 12 Feb 2004 (UTC)

Go for it. Mr. Jones 18:31, 16 Apr 2004 (UTC)

The article was already moved back over a year ago. What are the requirements for archiving a discussion? Derek Price 15:39, 4 August 2005 (UTC)

[edit] difference between Multiversion concurrency control and Concurrent Versions System

I'm pretty sure Multiversion concurrency control is different from Concurrent Versions System. But is it worth mentioning in the article exactly what the difference is ? --DavidCary 30 June 2005 03:27 (UTC)


[edit] GNU CVS versus alternative CVS versions

This article currently deals with something that has become almost a protocol with different CVS versions being produced and supported by different parties - including OpenBSD's development of their own in-house implementation. This article should probably split a bit more into a piece about how CVS works and leave the talk about the tools used for CVS in the Tools for CVS article - or alternatively it could simply add the Tools article to the bottom and have ths discussion on if GNU CVS is GNU or not above it. Either way, as it is, this set of articles seem a bit biased and unfinished at the same time right nows, so something should probably be done. Janizary 00:18, 19 August 2005 (UTC)

[edit] Explaining what "CVS version" of a software refers to

In technical discussions you often find references to the "CVS version" of a software. I think it'd be usefull to explain the specific meaning of this in the first few lines of the article. Josce

[edit] CVS and CVSNT

The article states:

"CVS uses delta compression for efficient storage of different versions of the same file."

This should be more specified, if it is mentioned at all. Only text deltas are stored, binary data are just copied.

Another "successor" of CVS, CVSNT, which was originally a Windows port of CVS, included many new features, like real binary deltas, and is also available for a couple of Unices as sourcecode. I think the article should at least mention it somewhere.

04.10.2005 TommyD

[edit] CVS, CVSNT and other variations - are they all "Concurrent Versioning Systems" ?

I'm adding this because the "Concurrent Versioning Systems" page says this is the place to discuss combining the articles on Distributed CVS and CVS.

Should the "Concurrent Versioning System" page hold information about all versioning tools, just the ones directly derived from the original CVS source, ones that implement the concurrent model, ones that *only* implement the concurrent model or is the "Concurrent Versioning System" page about the tool that goes with that name "CVS" and other tools should be allowed their own entries?

My vote is that the "Concurrent Versioning System" should be about "CVS" and should "mention" such tools as Subversion, CVSNT, Distributed CVS etc and that the authors of those products / packages should be free to create Wikipedia articles that describe what those products are and that such a factual description should be an allowable entry.

I work for March Hare Software who sponsor CVSNT development, and I recently tried adding "CVSNT" and "CVS Suite" articles (the free and commercial versions of CVSNT) to wikipedia and they were promptly deleted.

User:ArthurBarrett/CVSNT and User:ArthurBarrett/CVS Suite

With 1.4 million annual downloads (site visitors and page hits are a significant multiple of this) I believe that CVSNT does warrant some discussion in the wikipedia.

I freely admit to not being a frequent or regular contibutor to the wikipedia, but I fail to see why Subversion, Distributed CVS and other tools all warrant separate articles and CVSNT does not. The articles were originally banned due to concern that they contained copyrighted content, and once the copyright was clearly removed / assigned the articles were removed as marketing...

--Arthur 23:59, 29 December 2005 (UTC)

[edit] CVS Best Practices - 'a user-supplied description lines standard'

I'm trying to promote this "standard" to opensource community and maybe publish it as a Wiki article ("CVS Best Practices" ?). Would anyone suggest the best way to do it ?

CVS COMMENTS STANDARD

 <type> <effect> [bug reference] [<": "> <description>] 

  <type> ::= { +++  | !!!  | +  |  !  |   *  |  -  }  
    "+++" - new feature for WHAT"s NEW.txt
    "!!!" - bugfix for WHAT"s NEW.txt  
    "+" - new feature
    "!" - bugfix  
    "*" - modification   
    "-" - deleted feature

  <effect> ::=  {bomb | ui | core | func | internal | future}   
    BOMB - development-level massive partially tested changes
    ui - user interface  
    core - system core
    func - functionality change  
    internal - internal or cosmetic change, do not affect users or developers
    future - #ifdef-ed code that do not change compiler output 

  <bug reference> ::= <"#"> <number>  

  <description> ::=  // a comment, try avoiding redundant "added", "fixed", ...

Examples of common CVS comments (original comments are taken from: http://cvs.sourceforge.net/viewcvs.py/tortoisecvs/TortoiseCVS/src/DialogsWxw/)

 +ui: hidden cancel button.
 *core: 64-bit portability patches from ...... 
 !internal
 !func: applied patch from .... to make searching upwards working
 !ui #1194077:  colors wrong in annotate (issue 3). 
 !func #1221702: create Branch crowded/missing text. 
 *internal: Inherit from ExtDialog 
 +internal: Update to wxWidgets 2.5.4; avoid using Connect(). Warning: Comp..
 !ui: translation
 -ui: special Save dialog for Make Patch. 
 +internal
 *internal: goto is evil.


Mitra 01:19, 11 February 2006 (UTC) M_i_t_r_a

Great idea - but maybe better to post on one of the newsgroups like the TortoiseCVS newsgroup, the WinCVS newsgroup, the CVSNT newsgroup (which is the version of CVS that tortoise and wincvs both use) or the info-cvs newsgroup. My reaction that the "type of checkin" is better handled as metadata, eg: CVSNT has a separate "bug" metadata (used in Tortoise 1.9.x), and the CVSNT developers are considering a few other types. Typically installations use TAGs for this, not special characters in comments. Arthur 05:13, 11 February 2006 (UTC)

[edit] CVS vs. ClearCase

I would love to see some comparison betweem ClearCase and cvs. To me cvs seems perfect but I see many people still prefer to use ClearCase. I would like to understand why. ori 15:49, 26 March 2006 (UTC)

Perhaps a Revision Control comparison page with CVS, SVN, ClearCase, and others would be a good idea. --171.71.37.84 00:58, 4 November 2006 (UTC)
Comparison of revision control software --Imroy 02:07, 4 November 2006 (UTC)

[edit] CVS Implementation

I would like to see more information on how CVS can be implemented and used across organization for multiple projects.

Is that a bit like expecting the entry for a Fat_Man to include instructions on how to use one? I think the information you are looking for is in the manual that comes with the product Arthur 00:14, 10 November 2006 (UTC)

[edit] Infobox

Whats software with out an info box?

I have added one, please fill in the blanks --Amckern 07:36, 28 April 2006 (UTC)

[edit] CVS attempts to merge the changes?

I have a problem with this statement in the "Features" section:

When they later check-in their changes, the server attempts to merge them.

This is how SourceSafe works, but this is not how CVS works. CVS does merging on checkout, not checkin. What actually happens here is the second user's commit fails with an out-of-date error, compelling him to update his local copy, which will then be merged with the latest version in the repository. I think this is superior to the merge-on-checkin paradigm because you always have the ability to compile and test code before committing it to the repository.

At least, this is how I understand CVS works. Am I correct?

Yes, you are. I re-wrote this part as best as I could, though it sounds a bit clunky to me. Oh well, hopefully someone else will polish it further. — Frédéric Brière (✎) 04:09, 3 August 2006 (UTC)

[edit] Limitations? (Criticism and Misconceptions)

Ive been attempting to rewrite this section in such a way that it is a little less simplistic.

The phrase / heading "Limitations" itself is just a disaster - its full of preconceptions and opinion. The wikipedia sections on Democracy and Socialism don't have a section on "Limitations", they call it "Criticisms" which is more accurate. But writing truly objective criticisms are difficult, is anyone expanding the criticisms section on socialism automatically a democrat? Should the "criticisms" section merely be a bunch of links to other competing ideologies? The criticisms sections on democracy and socialism are both quite short and objective (I think) - to go further down that route with the CVS entry really requires that the other sections do a better job of explaining not just what CVS does and how it came about, but the theory behind it. I'm unable to dedicate the time to contribute that much so instead I'm just trying to make the Limitations section more objective and provide some specific examples of the arguments for and against (without getting into who is right and who is wrong, or who says what and who disagrees).

In its original incarnation this section was really just a promotion for other (competing) open source and commercial tools trying to push their POV. I certainly dont 100% agree with the CVS teams position on all these "limitations" but I think they have a point to argue, and that someone reading this page is interested in the pro CVS argument more than the pro SVN one.

Thanks to all those who are helping refine my argument - please dont feel like I'm just pushing one barrow here - hopefully I've incorporated all the editors arguments in a balanced way. But I'm also sure its not finished yet - go right ahead and improve on it and I'll keep my eye on it too.

One area I haven't touched on at all yet is "addons" like CVSWEB, ViewCVS, SCMBUG etc. People who have only used tools like ClearCase exect the SCM "vendor" to provide all the bits, wheras the Open Source method is to provide these as islands and leave it up to the user to combine them. I've heard many a PVCS and ClearCase user talk about the lack of defect tracking and build management in CVS as a limitation. This needs to be addressed somehow in this section, again not simplistically but with some care and thought to the different arguments.

Finally - my pro/against arguments on Unicode, symbolic links and rename are not intended to be comprehensive. The arguments I've given are both full of holes but I wanted to simply give "food for thought" to the casual reader. The saying goes "someone who can be argued into believing one thing, can be argued into believing something else". I'm not trying to create believers by my notes, just get people to think critically about both sides of the argument. I think the place for the detailed argument is in the wikipedia pages for each alternative. As I said above - really the whole CVS page needs more detail on CVS theory where pro-CVS advocates can go into the necessary detail about their arguments.

Arthur 01:23, 16 November 2006 (UTC)

On the refactoring/rename issue: I do believe it would be important to mention that moving the RCS file would be a bad, partial solution: in fact, it would break checkouts from previous versions because they would no longer compile, would they? They would expect the file to be somewhere else...
- LGon 22:18, 26 January 2007 (UTC)
Mathrick has added a criticism section and radically altered the limitations sections with the comment "Cleaned up the section. Removed dubious reasoning behind the limitations, added more, removed things that aren't obvious limitations and could be design decisions". I've explained my resoning quite well (above) on the talk page, and Mathrick has failed to address this in any way whatsoever on the talk page - so I'm simply reverting it back. The "Concurrent Versions System" is about the "Concurrent Versions System" - not about DCVS or about open source SCM or about anything else other than "Concurrent Versions System". Yes it's difficult to talk about things in isolation (try discussing renaisance art without mentioning baroque art) but people reading about CVS want to know about CVS. I maintain that the problems with a 'limitations' section focusing on 'criticism' is that it fails completely to understand that that was (and IS) the intention of the CVS Software developers. They are not limitations - they are (good or bad) design decisisions. Finally adding comments like "CVS was especially heavily criticised due to its near-monopoly status in the open source world for a long time." need to be substantiated. I've contributed to open source for a long time and never heard ciritism of a "monopoly" by any project - if this applies to anything it'd be Apache - the limitations section already covers the "yet another cvs" which clearly shows that there is no such monopoly and never was. Arthur (talk) 23:07, 11 February 2008 (UTC)

[edit] "client-server"

The ability to function as a client-server program is certainly one of the more important features of CVS from the viewpoint of developing with multiple programmers on different machines, but as written the sentence "CVS uses client-server architecture: a server stores the current version(s) of the project and its history, and clients connect to the server in order to check-out a complete copy of the project, work on this copy and then later check-in their changes" is incorrect. CVS works just fine on repositories stored on a local filesystem with no server running at all. Geoffrey Spear 18:11, 17 January 2007 (UTC)

[edit] "Creator" of CVS?

Cleaning up some of links in external links section, found this link, which by its title seems to claim Brian Berliner is the creator of CVS

It seemed strange that the creator of the item the entire article is about would not be mentioned anywhere in the article text? In the article text, though is a quote "I created CVS to be able to... – Dick Grune, Dick Grune's website" Will the real "creator" of CVS please step forward! Cander0000 05:56, 19 September 2007 (UTC)

On reread, I do see Brian Berliner mentioned in the history section, still unclear which of the two parties has claim to be the creator? Cander0000 06:06, 19 September 2007 (UTC)

[edit] What are the misconceptions

The following section, which I copied from the article, is unclear:

Common misconceptions about CVS include branching and distributed/multi-site/offline operation.
  • branching. CVS was the first version control system to implement branching and the branching techniques in other systems are all derived from the CVS implementation.
  • distributed, multi-site and offline operation was always heavily supported due to the unreliability of the few computer networks that existed at the time CVS was written.

This section does not really tell us what these misconceptions are. It says that branching is one of the misconceptions of about CVS. I clicked on branching to learn more about this misconception, but that article doesn't say anything about a misconception.

Should I conclude that "CVS was the first version control system to implement branching..." is the misconception? If thát is the misconception, what is the 'right' conception?

I am going to remove the incomprehensible part of that text. Johan Lont (talk) 14:28, 17 March 2008 (UTC)

I had discussed this already above (limitations and misconceptions) on the same talk page. But you've got a good point - misconceptions was not the right subject. A look at the history shows that I added that in response to people vandalising the page with propaganda about other tools and describing any feature of those tools as a limitation of CVS. The misconceptions heading was clearly in response to that. I think moving these into the body of the article is the correct place for them - but I feat the same issues are going to be raised again since the 'limitations' section does not adequately anticipate those future edits (even though these are features, and the fact they are 'missing' in CVS is a misconception not a limitation).

No idea how to 'fix' this so I'm leaving it as it now stands. Arthur (talk) 22:35, 25 March 2008 (UTC)