Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

Cyclic discontinues offering CVS support contracts 87

Posted by Hemos from the the-last-train-to-rockville dept.
raggy wrote in to say that Cyclic is discontinuing its' support for the CVS system. Existing contracts will, of course, be honored - however, with Jim Kingdon taking a job at Red Hat, CVS support is being passed to the community.
This discussion has been archived. No new comments can be posted.

Cyclic discontinues offering CVS support contracts More

Cyclic discontinues offering CVS support contracts

Comments Filter:

  • Re:More ... (Score:1)

    by Anonymous Coward
    Because CVS sucks. It costed our company way to much money just in the cost of the time it took to setup and get working right. We have about 2,000 developers and they just could not work with CVS. So we kep going with MS V C++ project mangement system. That worked fine.
  • >When I said "you can't run CVS disconnected" I mean really disconnected.
    >As in on a laptop on a plane.
    Yes, you can.
    >Before you say "yes you can" please consider that your definition of "can" is limited.
    >Yes, you can edit and modify files. Can you check them in? Nope.
    Yes.
    >Can you browse old history? Nope.
    Yes.
    >Can you reconstruct an old version of the repository and work on that? Nope.
    Yes. You're entirely wrong about every point you make here. What you do is mirror the CVS repository itself and use something like CVSup (www.polstra.com) to synchronize them.
  • So much for this [blockstackers.com] then, eh?
  • Posted by FascDot Killed My Previous Use:

    First the ontopic:
    "...there's a difference between thinking up and executing good code and choosing the tools with which to do that."
    True, but there's also a different between what information people use to make decisions and what information they SHOULD use. When Joe Programmer hears "Linus doesn't like CVS." or even "Linux abandoned CVS for something more ABC" he is going to chuck CVS.
    Now the offtopic:
    "Elf Sternberg"? Not THE Elf? I think I've read a few of your stories...
    ---
    Put Hemos through English 101!
  • Check page http://marc.merlins.org/linux/balug9906/
    where Linus is paraphrased as saying:
    About source management, Linus is convinced that CVS is indeed not the right tool, and he is going to give a serious look at Bitkeeper when it comes out (scheduled for July 15th). (Bitkeeper is from Larry McVoy, and you can see my report of his talk at linuxexpo if you'd like more info about it)
    --

    A bad review from Linus could be the kiss of death for a dev tool...
  • >It's all about open vs. close - does MS Source Safe work with ANYTHING except MS (n/n)?

    Yes, Metrowerks Codewarrior at the very least. We use it as the source control system for a Mac/Windows project with a high degree of common source.
  • See

    [red-bean.com]
    http://www.red-bean.com/ccp.html

    for details; this is a "CVS community" project,
    designed to ensure the stability of the
    CVS maintenance process and of the resources
    currently found at www.cyclic.com.

    -Karl
  • This comment doesn't make any sense at all...

    > Pinning support for hundreds(thousands?) of
    > users on one person in a company is just bad
    > policy.
    > Is there nobody at the company with the
    > required expertise?

    As stated in the atricle, there is only one full time employee.

    To answer your question, they now have no support available.

    This is not some big conspiracy or anything. The guy decided to move on. This is a pitful of free software. On the other hand there's the fact that this software is not just going to disappear. The comunity will now have the job of maintaining it, and anyone who wants to can provide support.
  • I really don't think that that much support is required for CVS as it is a really straight forward system, but corporations have a hard enough time going with it now; I don't see anyone using it without corporate support.

    The company I work for uses ClearCase and ClearGuide for code management and they are decent, but we have had all sorts of problems with mangaled code on checkins. The only advantages I see with it is the multi-version filesystem, which on a large project like this (several hundred developers and about 12 months) does save considerable cost in space, since only changed files must be saved on all systems, and the user interface (personally I like CVS's interface better. The GUI for this system is exteremely slow and the commandline options are more complex than CVS's, but I know many people perfer graphical systems.) The argument for training is rather mute because in any reasonably complex system you are going to have to spend time in training and I don't think the time it takes to train someone to use CVS is that much longer than the time it takes to train them to use a GUI based system. We had all sorts of problems with ClearGuide when it was installed, and I can't imagine taking more than 10 minutes to set up a CVS system so I don't think installation is very simple. I was really hoping that with Cyclic advertising and stuff CVS might get some corporate backing and make a take some marketshare, but I'm afraid that corporate use just isn't going to happen with out support and advertising.

  • I suspect people who are smart enough to use a version control system are also smart enough not to let Linus think for them.

    CVS is used for _many_ free software projects, for example egcs, who are known not to worship Linus.
  • Are they going to need a full time employee to support gcc, are are Red Hat going to do any development on the compiler as well?
  • For example, one of them latched onto the fact that CVS doesn't have exclusive checkouts like VSS and he claims it will make it impossible to work as a team if we can't know exactly who has a file checked out at any given time.

    As I recall, the CVS documentation says that if this is ever a problem then there is a problem in your process. People should know what others are working on. The doc go into more detail. that.

    Speaking for myself, I've worked with RCS which has pessimistic file locking like you mentioned. I found it more of a hassle finding a file was locked and having to bug people to check in their code, or breaking the lock because that person was on vacation and forgot to check everything in.

    On the contrary, a good habit to be in is to make small changes to the source and check it in. That way you discover conflicts quickly. It also requires you have good modularity in your projects, so changes are usually limited to one file and not scattered everywhere. For those cases which do require many large changes, they are big enough that you would have to tell everyone to stop working anyway (ie, under VSS you have to tell everyone to check their code back in.)

    Also, I have some concerns about how the automatic three-way merging will work with binary form files (can't do a diff/merge then) which our Oracle work uses.

    Take a look at the documentation section on binary files. There's an option, `-kb', to specify that a given file is a binary file, and there are options in cvswrappers(?) to specify how to to the merging. I believe you can specify your own way to do that.

  • I agree.. It's undermining the CVS user base by suddenly saying that they will, in the future, not have a paid way to provide support for the product. I'm honestly suprised that seeing as how much Red Hat uses the entire CVS system, that they don't take up where he's leaving off. Since he's there anyway, they may as well make money off it..

  • There is no MS Visual C++ managment system. There is Source Safe. And if you are relying on SourceSafe, you have one MAJOR DISADVANTAGE. You are RELYING on having some sort of drive mapping to the data files. Visual SourceSafe cannot, to my knowledge, work with a client that simply passes data thru a socket. Remote users now need the overhead of full fledged NetBUI over IP to use it..

    Don't even get me started on what happens when the drive goes down in the middle of a large update..
  • And I'd be interested to know what company you work for that has 2,000 developers, and someone as incompetent as yourself having ANY sort of position of authority?
  • Sure you can run disconnected operation.. Check in, Check Out, and Update.. I'm confused by your statement.. Please explain more..
  • I believe that's "Last Train to Clarksville."

    :^)
  • Perhaps you should reread the announcement. First, he's honouring all current contracts. He's not breaking any agreements.
  • This is just more proof that RedHat is every bit as evil as Microsoft! How dare they hire programmers. Or something.

    C'mon guys, help me out here.

  • Yes, evil Redhat! Luring open source developers away from their open source projects in order to work on RedHat's own twisted open source agenda!

    We're living in a world where a talented developer just can't starve anymore!

  • Regarding no file locking: You can in fact do locking with CVS, but it's just not the default. When I started using CVS (on a small 2-person Linux project) I initially used locking, but it proved so annoying that we've turned it back off, and haven't had a problem with bad merges. Consider also that largish teams like GNOME and EGCS use CVS all the time. If it sucked for team development, don't you think they would be using something else?

    Regarding CVS vs. RCS: forget RCS. CVS is essentially a superset of RCS, so there's nothing you'll gain by choosing RCS over CVS, and plenty you'll lose.

    Since I began using CVS on that project I mentioned above, I've since begun using it for my Windows code -- it works great, and it's not at all demanding. Basically, when I finish a significant update to one of my programs or libraries, I just type "cvs commit" at the command line and write up a short description of my changes. For that minimal investment, I get automatic source duplication (i.e. disaster protection), a running change log (both in terms of code and functional description), and the ability to roll back changes.

    Anyone who programs without something like CVS needs to be quickly and firmly reeducated. Similarly, anyone who pays big bucks for such a tool without first looking at CVS is doing themselves a big disservice.
  • VC/C++ doesn't have any source control system. Your comparison is inept. Visual Source Safe is the proper comparison. See my other comments on this thread for why not to use VSS.

    It's indicative of your quality as a programmer that you don't know what your tools do.

  • Re:CVS sucks anyway. (Score:3)

    by drig ( 5119 ) on Friday June 25, 1999 @09:21AM (#1833404) Homepage Journal
    Um... MS VC++ doesn't come with project management. DevStudio uses Visual Source Safe.

    VSS works by mapping the filesystem of the server and acting directly on the files. That way, a poorly implemented or malicious client could totally destroy the repository. It also makes it very difficult to use through firewalls and whatnot. The protocol used is NetBEUI, which is archaic.

    CVS uses TCP/IP sockets. It works through firewalls nicely. It has a couple GUIs that are at least as nice as VSS, so you aren't stuck in a CLI interface.

    I am currently using both systems. VSS at work and CVS at home. I found CVS easy to setup, easy to use, stable, robust and effective. VSS is easy to use and stable enough, but it's setup is difficult and the protocol issue is enough to drive our administrators to drink.
  • What about a non-reversible hash of the IP, though?
    ---
  • tkCVS does a good job for me.

    http://www.cyclic.com/tkcvs/ [cyclic.com]
  • Linus doesn't use RCS, he uses nothing for the kernel - just tarballs.

    He doesn't like CVS because it has obvious limitations which haven't been addressed in years:

    - no file name tracking
    - no change sets, grouping of changes across files
    - no support for disconnected operation

    That's why we wrote BitKeeper, check it out at
    http://www.bitkeeper.com - the Linux port to
    Merced is happening as we speak under BitKeeper.
  • When I said "you can't run CVS disconnected" I mean really disconnected.
    As in on a laptop on a plane.
    Before you say "yes you can" please consider that your definition of "can" is limited.
    Yes, you can edit and modify files. Can you check them in? Nope.
    Can you browse old history? Nope.
    Can you reconstruct an old version of the repository and work on that? Nope.

    In short, yes, you can modify files. Hardly what people want when they say "source management".
    Just being able to modify files is about the same as Linus' current tarball approach.

    With BitKeeper, the repository on your laptop is *identical* to the one on your server back home.
    In fact, if the server gets blown up, you've lost nothing. Everything is on your laptop.
  • Jim's best year was about 3/100th of 1% of the annual SCM market according to IDC.

    Those people who are unhappy about him bowing out of the game would
    have been better served by purchasing support from him.

    People can't be expected to work for free.
    Jim's best year was not enough to support one engineer at SGI or SUN.
  • Brian Feldman claims that CVSup is the answer to working disconnected.
    I can't really fault him for that since BK is publicly released yet, but I think he'll agree
    once he plays with it that it blows CVSup out of the water.
    Here are a few points: null resyncs take a few seconds in BK over 28.8 modems.
    BK can recreate the tree as of any point in the past trivially. I do this all the time to work
    on old releases:
    bk resync -r..beta9 /home/bk /tmp/beta9
    BK tracks renames.
    BK works through email if you want.
    BK supports compressed repositories (8 years of linux history takes 38MB).
  • I think it's rather irresponsible for any vendor to simply drop support - even if it is CVS we're dealing with. Pinning support for hundreds(thousands?) of users on one person in a company is just bad policy.

    Is there nobody at the company with the required expertise? If not, why did they start supporting CVS in the first place? I think it's a convenient excuse to get rid of the higher support costs involved in CVS. Not that this is entirely a bad thing. But if I was a customer of theirs, I might be asking a few questions along the lines of "what support do you have that *doesn't* depend on just a few critical personnel? How can you guarantee continuing support with the non-cvs versions?"



    --
  • Since every developer needs write permission on the repository's network share, you don't even need the malicious client - just have an idiot on your team!

    One project I worked on lost two days of work because someone got the bright idea that it would be neat to see what was inside the repo. Fire up Explorer, a few mouse clicks and...hmmm...anyone seen the backup tape?

    I just find it sad that MS still insists on selling braindead file-based apps when it's so fricking obvious that IP-based client/server works better.
  • So fix it. You've got the source...
  • Gosh, is there real widespread hatred of CVS, or are these all from the same Anonymous Coward?

    Anyways, the reason you see help questions on Usenet is because people will answer them. For free! That's what Usenet is all about. If you had trouble with SourceSafe, you'd call MicroSoft.
  • Hey Rob, why not add a feature to have the IP address of the posting host included along with each message next to the score and username? That way if a luser is posting many many flame/troll messages we can easily see them for who they are and ignore them.


    This would have the side effect of filtering out posts from good posters who happen to use the same ISP and are handed the same IP number for their session :/.


    OTOH, a couple of past cases make me think it might be worth it.

  • I can't even tell if this whole thread is supposed to be a joke or not.

    --

  • CVS certainly isn't a wonderful tool to use, but I find it highly, well, odd (to be polite), that Linus would think that it's `not the right tool.' He's currently using RCS, right? How on earth can he believe that RCS is better than CVS for what he's doing?

    I'd love to use something better than CVS for NetBSD, but that's the best free system that's out there at the moment, so that's what we use. And the FreeBSD, Apache, and many other folks seem to agree.

    cjs

  • He doesn't like CVS because it has obvious limitations which haven't been addressed in years:
    • no file name tracking
    • no change sets, grouping of changes across files
    • no support for disconnected operation
    Sure, I'm well aware of these limitations too. However, Linus' `solution' of using tarballs rather than a revision control system doesn't exactly address any of this, does it? It just removes all other revision control features as well. That's why I can't respect Linus' decision as a technical decision; technically, it's bad.

    CVS may not be the best that could be, but it's the best out there right now, and it's certainly a heck of a lot better than nothing. NetBSD has a half gig of code in the CVS repository with more than a hundred developers accessing it. Life without CVS would be very, very painful.

    cjs

  • "A bad review from Linus could be the kiss of death..."

    I doubt it. Linus is good at what he does but there's a difference between thinking up and executing good code and choosing the tools with which to do that. Alan Cox and Linus were far apart on their development environment of choice.

    I use Xemacs, TCSH, Gnu make and CVS for my environment-- they're what I know. Moving to something else after learning those wouldn't increase my productivity until I'd overcome yet another learning curve.

    Elf
  • For these sort of things, it is probably best to create a branch and develop your changes there. When you have completed them, merge the changes back into the head.
  • There is one called pharmacy which runs with GNOME. I have not used it personally, since I have found that the command line cvs program is more than sufficient.
  • The IP address would not be a good idea (there are reasons why people post as AC). It would be good to have a way to differentiate between AC's in a particular story.

    All that is required is a way to tell if two AC posts are from the same machine. I don't think it is a good idea to post IP address info, as this could be used to identify the person.

    On the other hand, something like this would require storing the IP addresses of AC's (I don't know if this is done right now), which could be bad if there was a libel case related to an AC post.
  • Exclusive checkouts is a bug, not a feature. Once you've tried working without them, you'll never go back.

    However, if you really want exclusive checkouts, you can use cvs watch and cvs edit.

    CVS doesn't merge binary files. If you mark a file as binary, CVS will reject a conflict, rather than attempting to merge it. You must then resolve the conflict manually.

    CVS and RCS aren't really comparable, although CVS is built on top of RCS. RCS provides revision control on a single file. CVS provides concurrent development on an entire repository.
  • It's possible to use CVS to check in code without others seeing it, but it's awkward.

    One approach is to use a tag, e.g., `stable', and have others do cvs co -r stable FILE. This will become a sticky tag in their working directory. If you check in changes, others will not see them until you change the tag. When you do change it, they will get the new version when they update. Of course, this only works if you are the only person working on that file.

    Another approach is to use a branch. Then you merge the branch into the mainline when you are done with your development, using cvs co -j.
  • He's currently using RCS, right? How on earth can he believe that RCS is better than CVS for what he's doing?

    CVS might not have much to offer Linus. Its most significant advantages over RCS are that it's network-aware, and it has a superior conflict resolution system. These are advantages that appeal to distributed development environments or large development teams. Linus is famous for allowing almost nobody in the world to touch his repository. These features wouldn't particularly benefit him.

    I don't think I can understand why someone would find RCS better than CVS, either. But I can understand why they might not find CVS to be a big improvement.
  • I think it's rather irresponsible for any vendor to simply drop support - even if it is CVS we're dealing with. Pinning support for hundreds (thousands?) of users on one person in a company is just bad policy.

    I don't think you understand. Jim Kingdon is Cyclic. They're not really a "vendor" in the sense that you seem to be thinking.

    I wonder if this isn't precisely the sort of misunderstanding that Jim was talking about in his message. People seemed to think that Cyclic was going to take care of all the future development of CVS, when it's really a free software project like any other. It's weird how if you attach a company name to a maintainer rather than the name of an individual, people come to the project with a completely different set of expectations, even if the actual situation might be practically identical....

  • And what do you store your code in?
    Lemme guess - bitmap?
  • http://pharmacy.learnrespect.org/
  • You probably don't give a FRA, but there are several GUI CVS clients, including WinCVS which is written in C++/MFC (www.wincvs.org).
  • A bit off topic, but a bit on topic too:

    We're a small software shop doing 99% Windows based work and most of the developers would probably prefer to use Visual SourceSafe instead of CVS, however I've recently decided that we will be switching to a linux-based solution, only partially because of the high costs involved in maintaining our VSS licenses.

    Some of my team are looking for problems w/CVS because they're scared of what they don't know. For example, one of them latched onto the fact that CVS doesn't have exclusive checkouts like VSS and he claims it will make it impossible to work as a team if we can't know exactly who has a file checked out at any given time. Also, I have some concerns about how the automatic three-way merging will work with binary form files (can't do a diff/merge then) which our Oracle work uses. I can't do anything about the tools we use, because it is dictated by the client we are doing the work for.

    Any solutions out there other than CVS? How does RCS compare for a small team of developers (4)? The only requirement that I have is that a version control system run on linux and run over TCP/IP. Thanks for any help.

  • So is DOS, yet Microsoft still depends on it.
  • Was there a lack of functionality in CVS that existed in MS C++, or just the lack of a pretty GUI interface?
  • No matter what algorithm you use to hash the IP, it can be brute-force cracked fairly quickly.

    The reason for this is that there are only 2^32 IP addresses with IPv4, and you don't have to search a good percentage of those (0.0.0.0/8 isn't allocated, 127.0.0.0/8 is reserved, 224.0.0.0/3 is reserved for experimental stuff including multicast...)

  • And some of us untalented ones are doing ok, too. :)
  • Your opinion might be a little more credible if you could ascribe software to its correct manufacturer (Borland and VC++?) or spell simple words.

    1. CVS (and RCS) archive text or binary. Try man cvs.

    2. Some of us, myself included, believe that text based code is superior. Easier to maintain (NB spelling). Easier to debug.

    3. Professionals devote time to learning their tools. Training wheels are for children.

    Happy computing :-)
  • CVS and VSS do nothing but keep track of files. Nothing more than a database and source directories. Any OS w a directory structure can do what you do. It only takes a few scripts.
  • Nice idea, really. I'm just paranoid regarding recent events.
  • The main difficulty that most programmers face when moving to CVS is that fact that it doesn't lock files. Programmers used to locking systems always believe it would be pure chaos without locking. However, locking systems like VSS and RCS have disadvantages, especially when a team is large or separated by several time zones.

    In fact, rarely do two person's changes to the same source file result in conflicts. CVS merges 90% of all changes with no intervention. When it can't it allows the programmer to manually resolve the conflict.

    I've used both types of systems over the last twenty years (including VSS, SCCS, RCS, etc.), and have come to prefer CVS. A GUI really isn't an advantage with a system like cvs, since you're not constantly having to use it. With CVS once you do a checkout, you have your own completely writable repository. Usually once a day you do:

    cvs update -Pd

    to merge changes in the master repository to your copy. The only other time you need to use it is on checking files in. It's not like you need to use it every time you want to edit a file. I consider it much more work to use a GUI-base locking system like VSS. You canstantly have to think about source control when your programming. With CVS you only think about it when you do a checkin.

    New programmers usually take a couple of weeks to get the mindset, but in the long run are more productive.

    As far as binary files, you need to mark them binary, CVS will not do deltas on them, i.e. each rev will be a complete copy.

    The only thing CVS doesn't do well is handle merges to files like MS resource files. Also the way DevStudio handle resource.h (storing next available resource in the file itself) make it somewhat touchy to automatic merges.

    After a week or two of really using CVS, most open minded programmers will adapt and begin to like it. And they'll never want to go back to a locking system.

    P.S. Someone will probably point out that VSS can be set to use nonlocking, but it doesn't have the intelligence to do automatic merges like CVS.
  • Hmmm... I've had this idea occur to me a few times over the last couple of years, but I just put together some notes last night and earlier today. Maybe some of us should get together, spec it out and code it:

    http://www.focusresearch.com /gregor/project_ideas/cvfs.html [focusresearch.com]

    --------------------
  • We have been using WinCVS to connect to a Linux CVS server for about 2 months. Zero Problems. I've never used Visual Source Safe so I can't say which is better but CVS is very nice.

    BTW, another project at our comp. disliked VSS so much that they also switched to CVS.
  • I don't think that the person who doesn't know that the proper name for "MS VC++ project management system" is "MS Visual Source Safe" is qualified enough to make claims about the quality of CVS.

    Do you notice your heart? Not until it starts hurting. That's the way the CVS is being used - seamlessly. Securely. Reliably. Configurably. Anywhere with C compiler. Without hype. Without wasting time clicking buttons and wondering "why the hell !!!!"

    It's all about open vs. close - does MS Source Safe work with ANYTHING except MS (n/n)?
  • There are several ways to do a private checkin. Other people have mentioned creating a branch, and that's a good solution.

    However, it's also easy to set up your own private repository and switch $CVSROOT to point to that when creating a workarea to hold your not-yet-release-quality changes. (Once checked-out, a workarea remembers which repository it came from.)

    Charles Swiger | chuck@codefab.com | Yeah, yeah-- disclaim away

Slashdot Top Deals

"Experience has proved that some people indeed know everything." -- Russell Baker

Close