Talk:Concurrent Versions System

Computing: Software / Free and open-source software Low‑importance

	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
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by Free and open-source software (assessed as Mid-importance).

NPOV / Criticism

User:WikiLaurent has marked the "Criticism" section as NPOV-section|reason=The table is presented in a "Criticism" / "You're wrong" format. Needs to be made neutral.

The section highlighted as NPOV was changed by User:AlanUS in March 2012 from a paragraph format to a 'tabular' format.

A neutral POV is one where sides are not taken - which is exactly the point of the criticism section - it argues for and against the 'cvs way' of doing things - addressing the opinion by some that CVS is merely defficient, when the authors of the product argue that it's not deficient - that there are strong design reasons for the strength of those decisions.

I disagree that the table is NOT written from an NPOV, but the easiest fix for the format is to restore the original non-tabular version from pre-22 March 2012.

Any feedback appreciated.

Arthur (talk) 07:43, 13 November 2012 (UTC)[reply]

Active Development or Not?

People keep claiming CVS is not actively developed. I've added clear citations that show that it has regular patches committed. Please do not simply delete stuff - particularly if there are citations. If you have evidence to cite that it is not active please cite it and ADD to the article. If everyone just deletes 2 lines then in a month there will be no lines left - that's not the way to write an article.

Part of the problem is that the word 'active' is subjective - I think active development is the fact that there is a bug report and someone fixes it. No bug report, no development in a mature product. Products that are new and full of bugs (subversion anyone?) have a lot more changes because a lot more bugs are reported and need fixing. To claim that CVS development is not active just because it's been written well and doesn't have a new bug reported every 5 minutes is unfair and unhelpful.

So I've tried to reword that paragraph without using the word 'active' so hopefully it's less ambiguous. — Preceding unsigned comment added by ArthurBarrett (talk • contribs) 00:07, 22 February 2011 (UTC)[reply]

OK - this section I added has been labelled WP:OR and deleted. I disagree. I'll slightly reword it and add it back.

Arthur (talk) 06:12, 3 May 2012 (UTC)[reply]

OK - User:Safety Cap - you have an opinion about whether CVS project is abandoned or not, and you have made some good arguments, but you also deleted any argument that differs from yours. NOT COOL. Do not delete other stuff without at least some attempt at discussion. This section has existed on the talk page for some time for this topic. I'll restore the stuff you deleted. see [[1]], in particular "It is not appropriate for editors to insert their own opinions or analyses." Arthur (talk) 04:52, 17 January 2013 (UTC)[reply]

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

Is there a reason to keep this section in the article? It has had the unreferenced section template up for over a year & seems to be WP:OR. I do not think the way it is phrased currently actually improves the article, even if references could be found. --Karnesky (talk) 15:27, 7 July 2010 (UTC)[reply]

I suspect there is a reason to keep it. Or several. Or something like it. When I speak to Joe Average and he tells me he's using CVS - a little digging usually find he's using TortoiseCVS (which includes and is written for CVSNT) or DCVS etc etc - very rarely is it this CVS. As discussed elsewhere in this article - it is the 'yet another cvs' phenomena - but in peoples mindshare they are all called CVS. OK - long time to make a point: to distinguish THIS CVS from all the others, Joe Average often calls it GNU CVS. This is OK - it's just a name - but I think this section helps clarify the literal meaning of 'GNU CVS' versus the popular name 'GNU CVS'. Alternatively all this could be put into a disambiguation article. Arthur (talk) 13:01, 10 July 2010 (UTC)[reply]

Softarch Jon has decided unilaterally to cut this section of the article, without discussing or addressing any of the points in the discussion page. So I've undone the cutting, again. Dear Softarch Jon : read the discussion page - and engage in the discussion. Arthur (talk) 08:54, 15 July 2010 (UTC)[reply]

I don't know if that is a very compelling reason to keep it. I'd say that being unreferenced (and apparently not easily referencable) are great reasons to remove it (though I agree that Softarch Jon overstepped here). --Karnesky (talk) 23:40, 15 July 2010 (UTC)[reply]

I've altered the CVS disambiguation article to call Concurrent Versions System the Concurrent Versions System (GNU CVS) instead. The may or may not help... I propose making similar changes on the article itself (to refer to CVS in this article as GNU CVS. This should make the section about the title 'GNU' more meaningful (in context)... Not sure if this is really a good idea... Arthur (talk) 21:54, 22 August 2010 (UTC)[reply]

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? Softarch Jon has decided unilaterally to cut large swathes of the article just like Mathrick did earlier (see above) for largely the same stated reason. The correct thing to do is to read the discussion and discuss the options presented and reason out your opinions

As already 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. Arthur (talk) 10:39, 7 July 2010 (UTC)[reply]

Softarch Jon has decided unilaterally to cut large swathes of the article again without discussing or addressing any of the points in the discussion page. So I've undone the cutting, again. Softarch Jon : read the discussion page - and engage in the discussion. Arthur (talk) 08:52, 15 July 2010 (UTC)[reply]

I don't know whether this is the same implied criticism that Softarch Jon had, but it seems to me that the claim that refactoring was uncommon at the time CVS was developed is very difficult to support. I don't buy it, personally, and I have never seen anyone claim it except here. The term refactor may date from 1992 (but I don't know, and we don't have a citation here) but I can't imagine evidence that the refactoring process was rarely performed during the 1986 - 1990 period. Moreover, I don't think refactoring per se has much relevance to whether CVS ought to be able to version renames. Refactoring may be a reason for a rename, but neither is it the only reason to rename a file nor does refactoring often necessitate a renaming of files. I think it would be more useful to argue the reality: that rename tracking is non-trivial in the abstract, even more difficult given the constraint of per-file history metadata (,v files), and something that a conscientious developer can do in CVS without good software support, if necessary. (I grant that modern rename tracking is better! But rename tracking in CVS is not impossible, it's just not automated.) dgc (talk) 19:42, 6 September 2013 (UTC)[reply]

I just hit upon this article for the first time today. What I was hoping to find was a short, simple summary of the reasons WHY so much of the world has (in fact) turned from CVS to Git, considering both are free, etc. I expected to find a section titled something like "Limitations", or "Criticism" (relative to the state of the art... to what most projects of substance are actually using today). But in the current article, any such sections seem to have been censored out entirely. Although the talk page suggests there has been a lot of prior work done to explain it. The decline or replacement of a major tool is certainly relevant to a discussion of the tool. Can we have maybe at least just 2-3 sentences briefly explaining why CVS is clearly NOT the first choice of contemporary developers (even among free software) anymore? The current end of the article misleads readers, sounding like it's "the tool of choice for version control" for "open source software" and that there have been continuing improvements. But surely stats like this: https://survey.stackoverflow.co/2022/#version-control-version-control-system merit some explanation. There are lots of detailed discussions out on the web (https://stackoverflow.com/questions/802573/difference-between-git-and-cvs) but a (less opinionated) sentence or two here would at least keep people from being badly misled by a reputable encyclopedia. DKEdwards (talk) 21:05, 30 June 2022 (UTC)[reply]

It's plain from the talk page (and from the Wikipedia guidelines): there were no reliable sources given to use as a basis for the section, and it was removed here. TEDickey (talk) 23:26, 30 June 2022 (UTC)[reply]

Yes, it's clear there have been deletions but that hasn't fixed the misleading state of the article. WP guidelines prefer improvements over deletions. And I doubt that purge is the only one given this conversation dates back to 2006. Over the past 15 years the article just seems to get systematically reverted to a misleading state rather than improving attempts at an up to date picture. DKEdwards (talk) 08:13, 3 July 2022 (UTC)[reply]

Architectural Criticisms

I have not been following the evolution of this page, but appreciate Arthur's effort to keep it focused on CVS and his attempts to encourage discussion of the tricky criticism issue here.

I came to this page recently while trying to argue within my organization for a transition away from CVS to a system more suitable for us. While the background I found was interesting and useful, I did not find anything helpful in the criticism section. The items listed were mostly low-level restrictions or design choices that aren't really very important. For example, I have seen a lot of discussion about the file renaming question (mostly elsewhere), but it seems to me that renaming source code files is not something that developers do very often, however irritating it is when the need occasionally arises. The same is true for unicode, binary files, symlinks, and so forth; if you regularly need these things, then CVS isn't a good fit. As long time users of CVS (since about 1995), our group has long since come to terms with these limitations (I think this is a fine word to use in this case).

What I was hoping to find was a summary of criticisms of the CVS architecture. Perhaps this topic it too wide ranging to be in scope for an article about CVS, but as the most popular of representative of this class of version control systems, it does seem appropriate. Many of these architectural issues have been explored in other systems, but it would be appropriate to describe the diaspora from its origin rather than in the scattered context of the many children of CVS.

Here are the architectural criticisms that I have of CVS:

"Revisions created by a commit are per file" (properly listed first in the existing section). The problem is that software development doesn't work this way. What you build, run, and test is a module. The focus on files was never a good fit to the development process and is a hold-over from RCS. Changes at the module level (e.g., bug fixes) must to be reverse engineered by collecting "related" CVS commits to constituent files.

"Expensive branch operations" (listed sixth). The trunk and branch organization forces the organization to concentrate on a few lines of development. There is no way to make private or preliminary commits. In our organization all forward development occurs on the head while branches are used for releases in the field. In consequence, I observe two operating modes: commit frequently and too early with limited testing, experimentation and review, or commit infrequently and too late with limited sharing and large multi-purpose commits.

Hub-and-spoke sharing model (aka client server). This innovation was the silver bullet that drove CVS to such wide popularity. What was wonderful in the late 80s and the early 90s, however, is insufficient for many organizations distributed by ubiquitous networking. CVS tightly couples commit creation with global sharing. The previous issues mean that commits tend to be imprecisely defined and badly scoped in time and content, and then only option is to share these commits with the entire team. In fact "share" is a polite way of putting it; commits from my team members are foisted on me when I have change of my own that I am trying to prepare for sharing (the upgrade before commit situation).

One could make a good case that the first issue is really a serious shortcoming of CVS. The other two issues are only a problem in certain types of development organizations. If the project is small enough the concentrated lines of development is fine. If the developers are either in a tightly knit group or working fairly independently, the hub-and-spoke sharing module is a good fit.

Like the rename issue, these architectural issues are also a matter of fitting the tool to the task. If you have the right kind of organization, the CVS architecture can be just right. But for larger or more distributed organizations, CVS is not a good fit.

What makes the most sense, I think, is to organize this section around the kind of situations where CVS excels. It is tempting to approach this as a features check list, but some of the issues are not best described that way. You could list hub-and-spoke sharing as a feature, but real question is how your development group is organized. On the other hand, maybe this level of discussion is out of scope for the CVS article and instead needs to be in a page titled "how to choose and version control system".

ota (talk) 21:49, 11 October 2010 (UTC)[reply]

Your three points seem to be already addressed in the article. Your per-file paragraph seems, more-or-less, summed up by the current non-atomic commits point of criticism presently in the article. Expensive branching is, as you say, already in the article. Client-server is summed up by "no support for distributed revision control". So, it doesn't seem to me that you propose adding anything that isn't in the article. You may be arguing for changing the way the article is organized/phrased, but I can't really comment on that unless you were BOLD and made the changes or were more precise with your proposal. Wikipedia is an encyclopedia and not a how-to manual. I realize that there is a bit of room in here for improvement within policy & that you might not have meant your suggestion of a how to article literally, but would also caution anyone reading this lightly not to overstep that bounds & would encourage posting of actual how tos to another site. --Karnesky (talk) 23:36, 11 October 2010 (UTC)[reply]

Thanks for the contribution ota. I agree with Karnesky that I think you are asking something outside of the role of Wikipedia.

However I also think that none of these issues you raised are limitations of the CVS Architecture or the GNU CVS implementation, - but perhaps of specific site installations. The CVS architecture itself is very very flexible - and the CVSNT implementation implements both rename and user defined change sets, and unpublished commits and module wide revision numbering (what SVN calls atomic commits) are on their way.

I personally run a one day training course on CM Design for our customers and this stuff you are raising is discussed in that in a lot of detail. I've tried to sum most of it up in the theory section of my book "All About CVS" but it scratches the surface compared with what can be discussed over two 3-4 hour sessions.

The section in the Wikipedia article keeps coming down to: are these criticisms and limitations, or are they valid design decisions? I think what you are asking is whether these design decisions then limit the flexibility of the tool to accomodate particular SCCM processes. If there was a good wikipedia article on SCCM methodology and process then this section could discuss (or speculate?) on whether the designers of CVS intended to support particular methodologies, but that's an awful lot of work that I'd sooner put into my own book ;)

At a purely personal level I think your team may be confused with SCCM processes, SCCM implementation and tools like CVS. Using CVS should NOT preclude you from using unpublished commits today - they are inelegant in CVS 1.11/1.12 and CVSNT 2.x but not impossible - ditto everything else. Yes choosing CVS does preclude the use of some SCCM processes - but not many, and CVSNT precludes you from almost none - in my opinion SVN precludes more processes than CVS and adds none. Arthur (talk) 03:05, 27 October 2010 (UTC)[reply]

Citations - How ?

The Wikipedia policy on sourcing is Verifiability, which requires inline citations for any material challenged or likely to be challenged, and for all quotations.

This is absolutely impossible for computing articles!!!!

As can be demonstrated in the above discussion on limitations - anyone who dislikes one computing tool and faviours another maliciously challenges any collection of more than 3 words in the article.

A 'citation is needed' for "Many Unix systems run in UTF-8 and so CVS on such systems handles UTF-8 filenames natively. For programmers working on Unix systems all with the same encoding then this response seems reasonable". This is a bit like requiring a citation for "Many people breathe".

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.

I have a big problem generally with computing articles that it is very difficult to make meaningful citations, eg: that CVS is less buggy than other version control systems so has less releases. One of the drivers of releases of software is bugs, so if there are less releases there are probably less bugs, but where am I going to find the research to cite? However people reading this Wikipedia article are clearly going to be interested in reasons why CVS releases are fewer than others even though it is active. How to answer the readers question whilst also being objective and providing citations?

There certainly are some quotes in the article that should be cited, but malicious challenging through citations is just unhelpful. In future I propose that anyone adding a citation request should give at least some grounds for ANY alternative opinion, eg: a contradicting citation

Arthur (talk) 10:39, 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]

Dick Grune developed a set of shell scripts collectively named "CVS". These were wrappers around RCS commands, and established the RCS ",v" structure as the foundation for CVS metadata. Brian Berliner redesigned these scripts as a C program. By the nature of that transition it was new code; yet it had an interop requirement vs the extant shells scripts and metadata specification, so it's clearly a descendant. I don't think this is under dispute, even if it's non-obvious. I propose considering this issue closed, and removing it next time the talk page gets archived. ^[1] dgc (talk) 19:27, 6 September 2013 (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]

"CVS introduced the implementation of branching into version control systems"

I just removed this disputed paragraph after reading the cited paper:

CVS introduced the implementation of branching into version control systems: the branching techniques in other systems all derive from the CVS implementation as documented in 1990.[cite to CVS II: Parallelizing Software Development article by Brian Berliner ] Whilst RCS did incorporate the concept of branches - they were for individual files only.

As user:Schily notes, the claim is trivially false (the term "branch" appears to have been coined by Eric Allman for sccs decades before), and, looking at the actual cited paper, I can't see anything supporting the claim. Perhaps I missed it, but is there anything that supports the claim? - David Gerard (talk) 12:06, 18 February 2015 (UTC)[reply]

There's at least one "however": the branching described by Allman is roughly equivalent to the branching used for RCS (we could digress on that, of course). It is for single files. There was no scheme for managing collections of files. http://web.mit.edu/gnu/doc/html/cvs_2.html gives some hints on how branching started in CVS: the "vendor branch". As I recall -- from having done an evaluation for a project I was developing at the time (and perhaps could find a specific source), the collection information started as a manifest maintained by the CVS administrator. That's more rudimentary than what one normally thinks of as branching in the modern sense, but it did evolve. The point to make from this is that the term "branch" as used by Allman was far different from its use today (except for the occasional person using SCCS or RCS), so the criticism as such is invalid. Branching techniques (rather than a supposed property right on the name branch) was apparently the intent of the deleted text. TEDickey (talk) 21:37, 18 February 2015 (UTC)[reply]

You are mistaken: If you use "changesets" the way they have been introduced by Larry McVoy for BitKeeper SCCS, then you just need to use a branch in the changeset file (using the single file branching methods from SCCS) in order to create a project branch. Given the fact that Larry previously worked for Sun in the SCCS group, he of course has been aware of the distributed and project enhancements from Sun (NSE) on top of SCCS, he most likely has been influenced by NSE and TeamWare. Both predate CVS, BTW: NSE is from early 1986. In order to restore the removed claim on CVS, we would need to get a verification for the claims that CVS was the first and that CVS influenced others. The available information lead to the assumption that the converse is correct. Schily (talk) 10:04, 19 February 2015 (UTC)[reply]

The discussion is about branching, not changesets. If you have any verifiable, reliable source to present on that topic it could be of interest. Your unsourced, verging on original research comments are not of interest to anyone. TEDickey (talk) 02:04, 20 February 2015 (UTC)[reply]

The removed claims in the article dealt with branches to projects - this are branches on changesets.....and in case you don't know: a changeset is a group of single file modifications that was applied to a project as an apparently atomic delta.

If you have verifiyble and reliable sources for the removed claim in the article: "CVS invented branching", I would be willing to add it again. Schily (talk) 10:58, 20 February 2015 (UTC)[reply]

@Tedickey: Was there anything in the referenced paper to support the claim that "the branching techniques in other systems all derive from the CVS implementation"? I didn't see anything in the paper that talked about influence at all. It's a plausible claim, as you note, but that didn't make it - David Gerard (talk) 13:29, 20 February 2015 (UTC)[reply]

Not as it was phrased - the point that I mentioned at the beginning of this thread. However, I noticed the comment because (a) the change comment for the tag was misleading at best, and (b) it led to removal of a useful source for the topic without discussion. The normal thing to do would have been to amend the text to fit with the source. TEDickey (talk) 23:26, 20 February 2015 (UTC)[reply]

The removed link by the way probably matches the (inacessible) link referring to Berliner's paper. Written in 1989, the ".ps" file at least comments on NSE as of 1989. None of the sources which I have found describing NSE in any way relevant to this discussion precede 1989. So comments implying that CVS (originally 1986) copied from NSE do not appear to be factual, nor does a reimplementation of CVS in 1989 imply that either. As usual, links and details about WP:RS are what this discussion should be about. TEDickey (talk) 02:01, 21 February 2015 (UTC)[reply]

stray references

^ Grune, Dick. http://dickgrune.com/Programs/CVS.orig/. {{cite web}}: Missing or empty |title= (help)

latecomer as pioneer

CVS started in 1986, and the current C program started in 1990. Referring to a configuration dating from 1999 as pioneered is essentially promotional. Latecomers aren't pioneers in any sense of the word. Rather, the feature should be presented as addressing a specific need, using reliable sources to show when the need was first commented upon publicly, and how it arose. TEDickey (talk) 09:22, 1 October 2015 (UTC)[reply]

anoncvs was/is not a "configuration", it was/is a separate program that wraps cvs. When it was first implemented, it also required patches to the cvs server code to work. Source: [2]

anoncvs has existed since 1996, not 1999. Source: [3]. 1996 may still seem "late" but, as said above, prior to anoncvs' implementation in 1996 the functionality to grant read-only access to a cvs tree did not exist.

pi•o•neer n. "One who opens up new areas of thought, research, or development". Source: The American Heritage Dictionary of the English Language, 4th Edition

New area of thought: give anonymous users access to the CVS tree. New research: make it work and secure it. New development: implement read-only functionality into the cvs server code and create anoncvs.

Given that your opposition to the assertion and its wording was predicated on factual and historical inaccuracies, and a lack of knowledge of the English language, I have removed the discussion tag from the article. 111.69.242.235 (talk) 21:24, 4 June 2016 (UTC)[reply]

Dead project?

Is CVS dead? Soon it'll be 10 years since the last release. 2A02:8388:1600:C80:BE5F:F4FF:FECD:7CB2 (talk) 22:59, 21 October 2016 (UTC)[reply]

Since "death" is permanent, an accurate portrayal is "inactive". The infrastructure to resume development is still in place. – Conrad T. Pino (talk) 23:39, 21 November 2016 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Concurrent Versions System. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20110718233416/http://www.red-bean.com/sussman/svn-anti-fud.html to http://www.red-bean.com/sussman/svn-anti-fud.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:08, 29 November 2016 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Concurrent Versions System. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20121113100506/http://ximbiot.com/cvs/cvshome/docs/ to http://ximbiot.com/cvs/cvshome/docs/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:30, 12 August 2017 (UTC)[reply]

Lead section

I feel like the lead section needs to be rewritten as it looks more like it is about the history of the subject rather than the subject itself. ^{[Username Needed]} 11:35, 25 September 2018 (UTC)[reply]

text modified

CVS can checkout a file based on a date or a revision number.

However someone has changed this to ""(but not by revision number as there is no project-wide revision number)"

Well, you can't checkout using a colour either. This editor seems to be familiar with a version control system that uses project-wide revision numbers and thinks it's worth nothing that CVS isn't like this other version control system. This article isn't a comparison though, it's an article about CVS.

The best I can do to fix this sentance is:

Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project (eg: based on a given date).

Arthur (talk) 07:03, 3 October 2019 (UTC)[reply]

Adoption and successors section

In Concurrent_Versions_System#Adoption_and_successors it starts with a quotation that is quite a bit of "it changed the world" talk. I think the last sentence in the section, after the quotation is fine, and could be expanded, and maybe with a link to Comparison_of_version-control_software. I know CVS was heavily used back in the day, but it might be difficult to document that. MeekMark (talk) 17:46, 6 August 2021 (UTC)[reply]

[1] Grune, Dick. http://dickgrune.com/Programs/CVS.orig/. {{cite web}}: Missing or empty |title= (help)

[1]