Talk:Concurrent Versions System

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Infobox

Whats software with out an info box?

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

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)

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)

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)

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)

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)

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)

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)

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)

"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)

"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)

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)

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)

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)

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)

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)

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)

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)