Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems News

CVS Infrastructure 173

Posted by michael from the diff-on-steroids dept.
LiquidPC writes: "ONLamp.com has an article on FreeBSD's CVSup servers, which includes hints and guidelines on using CVSup. Also, advice from John Polstra, designer of CVSup."
This discussion has been archived. No new comments can be posted.

CVS Infrastructure More

CVS Infrastructure

Comments Filter:

  • The article largely boils down to common sense tips, so I'm not sure why this is newsworthy. Is it really newsworthy to know that if there is a mirror, consider moving at least part of your load to that mirror?

    Still, some good common sense information can be found, and the article is worth a read.

  • cvsup makes it tolerable to have a cvs client, which concurrently does the recentness compare with the downloads itself -- no BIG...LONG...PAUSE for a cvs update to scan everything then download the changes.

    unfortunately it's still ultimately based on the highly excreble CVS, which still can't handle something as simple as a renamed file, to say nothing of the hell it puts you through for directories. If McVoy would stop playing silly license games with Bitkeeper so he can try to become the next Sourceforge (sorry, but you lost), then the world would probably beat a path to his door.

    In the meantime, are there any robust and free alternatives to cvs?
    • I've been using CVS for five years, and although it took me a while to learn its twists and turns, I now think that it is an absolutely excellent piece of software. I have been forced to use other major alternatives at various companies I've worked for (the most notable being Perforce and MS SourceSafe) and CVS is vastly superior to the others I have used. (I have not used Bitkeeper, so I can't compare it.)

      Granted, it is missing a few important features such as the ability to flags files as having no revision history (so that large binaries can be stored without killing the server on commits and updates) and the ability to rename files and directories. But those are relatively minor complaints compared to all that it does do well.

      The project I'm excited about is Subversion [tigris.org].
      • I have been forced to use other major alternatives at various companies I've worked for (the most notable being Perforce and MS SourceSafe) and CVS is vastly superior to the others I have used.
        What didn't you like about Perforce? I found it much more powerful than CVS.

        The best feature was atomic commits, so you could look through the changelog for the repository as a whole rather than having to do it for individual files. Being able to see "Fixed bug foo - affected foo1.c, foo2.c, foo3.c" and "Fixed bug bar - affected foo1.c, bar1.c, bar2.c" was much easier than with CVS (where you get individual change logs for foo1.c, foo2.c, foo3.c, bar1.c, and bar2.c and have to cross-reference yourself to find out what files a particular bug-fix touched).

        Perforce is quite expensive, but a two client license is free so it's worth checking out.
        The project I'm excited about is Subversion.
        Definitely looks like it has potential - it supports atomic commits as well.

        -dair
        • Doesn't take much work to do that with CVS either. Where do you think all these 'project histories' keep coming from?

          As an example, we mail commits to a mailing list and store them in a linear log (as you suggest). CVS has the hooks, and writing a quick perl script to do the things you need really are quite simple. Umm.. if your using cvs the assumption is you can code anyway :)

          HINT: Look at the CVSROOT/loginfo file for that kind of thing. It even has the example you're looking for in it.
        • Just fucking sucks. I mean it's a useless piece of trash OS. Hell so is *bsd, windows

          My name's Ed sweetman and I'm a pig fucking idiot

    • CVS bad? (Score:3, Insightful)

      by Anonymous Brave Guy ( 457657 )

      CVS may have its flaws, but they are relatively minor compared to most of the competition. Sure, you can't rename/move things conveniently, which is irritating, but how often do you want to do that in reality? Not very, surely. Given the technical complications with moving a file (which might be branched, and so on) I can live with this.

      We switched to CVS some time ago at work, when we needed our MLOC project source base to be accessible to people working from home or clients' sites. So far, it's proved pretty successful. We're prepared to sacrifice a couple of little things in exchange for a robust mechanism for remote file access and a decent set of tools for integrating changes from many people.

      I should note that we also use WinCVS [cvsgui.org], which does make certain tasks easier. For example, you can do an atomic commit of multiple files from all over the source tree easily this way, much more easily than from the command line. Most of the awkward things about CVS are handled by using a decent GUI on top of it, in our experience.

      • CVS has a number of flaws, yes, but I still use it in preferance to any other SCC I've tried. Unfortunately CVS development seems to be a bit stale, at least in terms of innovation. There are a couple of improvements that could really improve CVS a lot.

        Things We'd Like To See(TM):

        • Atomic commits.
          They can be useful, and lots of people go wild about them.
        • Hierarchical module naming / access.
          For those who have used Visual Sourcesafe you'll understand - you don't have to check out a project; you can "root" your checkout at any point in the tree. You "projects" (modules) can also be classified in a hierarchy, instead of being a list in the modules file.
        • Linking files between modules.
          Code reuse is important in many environments, and often a file needs to be reused across several projects, without being a completely separate library. Several SCCs can link files across projects, including VSS. While I'm sure you can fiddle the server (on Unix systems) with ln, there is no CVS-provided means (via the client) for linking files.
        • Renaming files.
          This happens more often than people care to admit. Its easy on the server, but you can't do it from the client without deleting and adding, which means you lose the history (which is what SCC is all about).
        • Multiple CVS servers.
          This is very pertinent to the use of CVSup (at least, it was last time I tried - haven't used distributed repositories in about a year). Although you can check out from a slave repository, you have to check in to the master. This means that you have to use -d on every checkin to specify the master. CVS needs a built-in mechanism to tell it where to check-out, and where to check-in.
        • Backup.
          One of my pet peeves, since I have to work in a commercial environment. I need easy, reliable backup. With CVS, I have to write a script to do this for me, and consider the locking of directories, etc. Since I'm one of the few people in the company with Unix knowledge, this puts CVS on the "dangerous because of maintenance" list, and makes it unpopular.
        • Built-in transfer security.
          CVS over SSH is nifty and solves the security problem, but its certainly not easy, especially to set up as a server, and especially if you are trying to run your server under NT! CVS needs a built-in secure transport layer (say, SSL) either as a default or as an option.

        Well, thats my 2c.

    • Take a look at Aegis. It supports quite a few nice things CVS does not, such as atomic commits, and changes are handled as "change sets" - so a fix that touches multiple files can be applied and backed out in one step.

      It has been around for quite a while, and looks fairly mature. I haven't used it yet, but I'm reviewing it now for future use.

      http://www.pcug.org.au/~millerp/aegis/aegis.html

    • CVS has some big flaws, but it is quite nice. I haven't seen a source code control system that didn't have problems. Anyway I think you should look at subversion [tigris.org] they are directly addressing CVSs big flaws. It looks like the authors know a lot about CVS, and like CVS, so whatever they build will probably not suck more then CVS...

      ...except they have a lot of dependence on Apache and the DAV module. So that part at least sucks differently then CVS, and maybe more. Hopefully subversion will get far enough along that I can find out for myself though.

      If McVoy would stop playing silly license games with Bitkeeper so he can try to become the next Sourceforge (sorry, but you lost), then the world would probably beat a path to his door.

      Bitkeeper does look cool. I don't think subversion can do the same sort of hierarchy of repositories that bitkeeper can. Anyway I don't think McVoy wants to be the next SourceForge (are they making money?), he want to be the next PerForce, CodeSafe, or whoever else has made a ton of money directly off version control software.

      In the meantime, are there any robust and free alternatives to cvs?

      No, unless by "robust" you really mean "alpha quality, not trusted to be self hosting yet". Try again in six months :-)

    • Instead of asking other people "In the meantime, are there any robust and free alternatives to cvs?" why don't you take some time and help out the CVS or the subversion projects? I am sure they would be grateful for any contributions you may want to make. That's how open source works you know.
      • > That's how open source works you know.

        It never fails. Ask for advice, and at least one person tells me to do it my damn self. Clue check, this particular little advocacy tactic is really counterproductive. If you can't answer the damn question, keep your righteous cheerleading to yourself, ok?
        • Why is it that the world owes you great and free software. If you want to buy it then by all means write the check and get yourself sourcesafe or starteam or whatever. If you want it for free then get off your ass and do some work. If you can't code (well why are interested in source control anyways then?) then go write some documentation. All these projects could use a hand in some form or another.

          If you are willing to do neither then shut the fuck up we have better things to do then to listen you bitch and moan.
      • Why give the guy a hard time for doing a little research? If there were a "robust and free alternative to cvs" would you recommend that he ignore it?

        Personally I use CVS for ASIC development and am pretty happy with it. We use tools on Solaris, Linux, and Windows 2000 in the course of developing and verifying ASICs and it's nice to have a tool that works well on all of the above. You should see the mess that a lot of hardware engineers create...

  • why not use some sort of load balancing to redistribute/redirect the load to other mirrors around US?
    • why not use some sort of load balancing to redistribute/redirect the load to other mirrors around US?

      Because it would be killer for bandwidth. A better solution would be to put smart (ish) selection of mirrors into the client. Unforunately it's written in Modula-3, so you won't see me hacking around with it in the near future.

      Dave
  • ROFL. Hourly updates via cron? Sounds quite a bit exessive to me. Weekly ought to be enough for anyone. Anyway, props to a good system for keeping systems up to date without doing any real work at all.
    • Well.. If its a portion of a system that you are working on with others then it IS very important to keep up to date.


      I am working on the Linux HA [linux-ha.org] Procject by porting it to FreeBSD (and helping out with Solaris as well)... and I need to keep my system totally up to date.

    • well depends on your application. if u r involved in development work then you might need the hourly update From the article """ Think about how often you need to update. Are you really going to build FreeBSD from source every hour? If not, why upgrade your source code every hour? Developers need rapid access to changes, of course, but many users don't have to update their source as frequently as they do """ that point is answered in the article !
    • Personally, unless you're in a mission-critical environment, i seriously doubt that you need to update the system EVERY hour on the hour.

      I have suspicions that some people dont even realize they have these said cron jobs still running

      • If you are running a mission critical machine, it generally isn't wise to just install updates without waiting to see if there are any hidden problems in them. Of course, this doesn't apply to security fixes. Of course, that's why many things have multiple branches: stable, unstable, etc. The 'stable' code ought to be good enough to blindly install on mission critical boxes.
        • The 'stable' code ought to be good enough to blindly install on mission critical boxes.

          That would be a very bad idea. Stable is a relative term. Subscribe to the freebsd-stable mailing list for a while and you will see what I mean. Stable is more stable that current, but it is still a moving target with occasional glitches and bugs. Stick to the release versions if you want to be conservative. Even then, you need to test a new release before using it for mission critical functions.

  • This is getting out of hand...might be time to go back to the old slashcode.

  • I really enjoy the update process employed by FreeBSD. Superior to Debian's, which is the best in the linux community.

    Check it out. Also peruse the BSD lisence.

    The only reason I'd go back to Debian is convincing the pointy haired boss at work. FreeBSD is such a great OS, but no publicity. Wish I could get some servers up at work :-(, tough sell.

    cheers
    • Pointy haired bosses can't tell the difference from one x86 unix to the next. Just make sure that everything that says FreeBSD in the login screen and motd is changed to say linux and you'll be fine. If you have approval for linux, just install FreeBSD or OpenBSD and don't tell him/her :)
  • My complaint with CVSup is that there's no commandline client! Since I often do work on remote servers with X ports firewalled, this is a bit of a problem for me.

    Moreover, the GUI for the client is just *ugly*. It's this really bad pink colorscheme with Motif style widgets.

    The software works really well as far as doing updates quickly and in a minimum of network traffic, but it's completely beyond me why the default client is GUI only. I've also searched for commandline tools but have yet to find anything, anyone know if such a beast exists?
    • cvsup -L 2 -g supfile

      does the trick on my system.

      The -g switch disables the GUI.
      • Or you just slap these lines in your make.conf:
        SUP_UPDATE= yes
        SUP= /usr/local/bin/cvsup
        SUPFLAGS= -g -L 2
        SUPHOST= cvsup11.freebsd.org
        SUPFILE= /root/stable-supfile
        PORTSSUPFILE= /root/ports-supfile
        DOCSUPFILE= /root/doc-supfile

        and type "make update" in the /usr/src directory.
        It will update everything in one fell swoop src, ports, and doc.
    • My complaint with CVSup is that there's no commandline client! Since I often do work on remote servers with X ports firewalled, this is a bit of a problem for me.

      /me looks around for crack pipes
      You can either pass cvsup the -g flag as anothre poster noted, or just not have your DISPLAY environment variable set. This is not obscure knowledge... it is clearly documented in the man page and various tutorials.

      Moreover, the GUI for the client is just *ugly*. It's this really bad pink colorscheme with Motif style widgets.

      Umm... it uses TCL/TK IIRC.
    • The CVSup GUI was really more of a debugging tool than something that was supposed to be useful. Ask Polstra.
  • "Polstra suggests looking at your watch to see where the second hand points at this particular moment, and use that number of minutes past the hour."

    Um, what's a "second hand"?
    • The problem of 'everybody deciding to update their mirror at exactly 12 midnight' is an issue for more than just CVS.


      I first ran into this at $VERY_LARGE_CORP where every machine was built off a standard image, which included a cron job to synchronize the clock with the master NTP server every hour, on the hour- which meant that precisely on the hour, the NTP server got slammed with hundreds of requests for the time.


      I'm not sure why nobody has adopted my solution to the problem of ensuring that all the hosts do not hit the server exactly on the hour- the 'rsleep' command.


      RSLEEP(1) MSG.Net General Commands Manual RSLEEP(1)



      NAME
      rsleep - suspend execution for a random interval of time


      SYNOPSIS
      rsleep seconds



      DESCRIPTION
      The rsleep command suspends execution for a minimum of 1 second, and as many as seconds.


      Primarily useful for scheduling cron jobs to introduce some 'jitter' in the timing of requests from numerous clients all built off the same image, for example:


      5 0 * * * rsleep 300; ntpdate -s ntphost


      Credits
      This incarnation of rsleep was first implemented by MSG.Net in 1994 as a 'ksh' script.

  • Is anyone here using CVS with Project Builder.app on Mac OS X 10.0.4 and the release Development Tools? I am a new Carbon C developer and I'd like to set up a centralized repository for version management and file recovery.



    When I use Project Builder, the capability to use CVS is dimmed out. I checked in Terminal.app and cvs is installed and working correctly. (cvs -h works) How do I configure it to setup to connect to a CVS server and corresponding project so that I can commit my sources?



    Thanks for all your help. Have a good morning!



    Pat

    • How do I configure it to setup to connect to a CVS server and corresponding project so that I can commit my sources?

      Same way you normally would? Check out an existing project with "cvs -d user@server:/path/to/cvsroot get projectname"

      It works for me under OS X at least. Try reading the CVS FAQ for help. Or any CVS FAQ google turns up.

      Setting up your own repository is a bit harder. One way around that is to open source your project and have SourceForge set up a repository for you. You get free off site backups that way :-)

      • stripes, thanks for your reply. I've been able to use CVS to grab projects from SourceForge with no problem.

        More specifically, I was looking at how I can use ProjectBuilder.app's CVS integration. It has a whole menu for revision control and it is supposed to be integrated with ProjectBuilder. I'd like to use it to commit my changes to an upstream CVS server, is it looking for an environment variable to be set or something?

        Thanks for your help.

        -Pat

        • More specifically, I was looking at how I can use ProjectBuilder.app's CVS integration.

          The help files claim the CVS stuff works if you are working on a project already under CVS. So i guess checking whatever your working on in, and out again should make that stuff work.

          I have never tried it though, I didn't even realize it was there. Using a GUI to write and manage code is still new to me :-)

          (well, to be honest I used a crappy on on the Atari ST where I first learned C...)

        • I think you may need this in your environment:
          CVSROOT=pserver:user@server:/path/to/CVSROOT
          You should then be able to use ProjectBuilder to check out your project.
  • the big problem with cvsup is that it's written in modula-3. the only modula-3 compiler is for x86 only.
  • That cvsup is one of this coolest things about *BSD. It's more or less the reason why I choose FreeBSD over Linux when admining servers. It's make the administrative job of updating and securing your machines so easy.

Slashdot Top Deals

"The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud

Close