Talk:Concurrent Versions System

Please add {{WikiProject banner shell}} to this page and add the quality rating to that template instead of this project banner. See WP:PIQA for details.

Computing Stub‑class

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

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

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)[reply]

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)

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)[reply]

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

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

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)[reply]

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[reply]

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)[reply]

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)[reply]

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)[reply]

Comparison of revision control software --Imroy 02:07, 4 November 2006 (UTC)[reply]

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)[reply]

Infobox

Whats software with out an info box?

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

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)[reply]

Limitations? (Criticism and Misconceptions), not speculation, not dubious

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)[reply]

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)[reply]

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)[reply]

Please not that atomic commits are now possible with commitid. See http://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/NEWS —Preceding unsigned comment added by 206.191.39.213 (talk) 17:38, 26 May 2009 (UTC)[reply]

Dubious? Speculation? Original Research? As discussed above this section has LOTS of problems, however removing large swathes of it doesn't help. This section is attempting to describe the reasons why the developers of CVS made the choices they did. The developers deliberately CHOSE NOT TO VERSION SYMBOLIC LINKS. A quick google search shows there are lots of OPINIONS about this, but this article is about CVS and the decisions the CVS developers made. Discussion about whether they were the right decisions belongs elsewhere. I have personally been involved with the development team for about 8 years and have spent time discussing these decisions with the developers who made them. If you have specific information to the contrary that a feature is listed that is DIFFERENT to how described or the reasons for implementing it that way were DIFFERENT then you can amend the article, or even better - discuss it here. But if you simply think the listed reasons are DUBIOUS then that opinion doesn't belong in this article - maybe an article about the development of revision control and change control systems generally. This article is entirely about CVS, and if you like some other version control tool that made different decisions about what features to implement and how - this article is no reflection on your choice. The big problem WIKIPEDIA has with this article is that it is mostly based on private unannotated research, because there is very little written elsewhere about the history and the development team themselves. 146.87.6.75 (talk) 10:09, 7 July 2010 (UTC)[reply]

"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)[reply]

"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

Interview with Brian Berliner: CVS creator

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I'm removing the part that says CVS introduced the implementation of branching into version control systems: the branching techniques in other systems all derive from the CVS implementation .... CVS was based on Walter Tichy's RCS, which as far as I can tell had branching from the start, circa 1982. Maybe SCCS had, too. JöG (talk) 08:52, 12 June 2010 (UTC)[reply]

I've undone that change (sorry). Whilst RCS did incorporate the concept of branches - they were for individual files only. In fact RCS is not really a version control system in the modern sense. Alternatively since CVS started as a perl wrapper around RCS you could combine the RCS and CVS articles into one. As I wrote above - this paragraph got added due to vandalism on the page - people trying to turn the CVS article into an article about OTHER subjects and reference is provided in the article for an external document from a member of the original development team about the originality of branches in CVS. Does this really need to change - what purpose is removing this paragraph serving - does it make the article clearer, or less clear?

Arthur (talk) 10:40, 30 June 2010 (UTC)[reply]

svn release date incorrect

This page says that svn was released in 2004. The changelog the footnote refers to says that it reached version 1.0 in 2004, which isn't the same as being released. Each project has variable ideas of what version numbers mean. It also contradicts the Subversion page, which says that svn was released in 2000. —Preceding unsigned comment added by Ricky Clarkson (talk • contribs) 10:38, 31 October 2008 (UTC)[reply]

The reasoning is that all the references in THIS article , and in particular in the paragraph about "Yet Another CVS" all the dates referred to are "stable" dates. If we cite the "project started" date for SVN then we should do the same for everything else including CVS itself. I personally do not think that a "project started" date is very useful in this context since there are many many many tools that have attempted to replicate CVS functions that have "started" but never released a stable release and have subsequently become inactive. Finally this is an article about CVS, not about SVN or any other "yet another cvs clones", so the reference is merely anecdotal. The correct place to write about the history and development of SVN is on the SVN article. I have cited a reference to the SVN changelog to show where the date comes from, and anyone checking the reference will see that there were many non-stable releases going back to 2000. Arthur (talk) 06:56, 18 November 2008 (UTC)[reply]

Terminology Usage Question

Should terminology be used before it is defined? I am referring specifically to the usage of the word 'commit' in the third paragraph under the Features heading, although there may be more than one instance. I am not much of a wiki editor, I simply thought it would be appropriate to bring this to the attention of people who are. —Preceding unsigned comment added by Gungfusteve (talk • contribs) 00:11, 6 December 2009 (UTC)[reply]