Posted by
michael
on 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."
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 finally had it: until slashdot gets article moderation, I am not coming back.
Re:cvsup good, cvs baaaaaad
by
Adam+Wiggins
·
· Score: 2
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.
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.
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.
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 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:-)
Re:cvsup good, cvs baaaaaad
by
Malcontent
·
· Score: 2
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.
--
War is necrophilia.
Re:cvsup good, cvs baaaaaad
by
scrytch
·
· Score: 2
> 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?
-- I've finally had it: until slashdot gets article moderation, I am not coming back.
Re:cvsup good, cvs baaaaaad
by
Malcontent
·
· Score: 2
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 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.
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.
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, 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.
-- If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
-- i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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?
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?
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...)
RSLEEP(1), for distributing requests over time.
by
Nonesuch
·
· Score: 2
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 rsleepseconds
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.
BSDs should develop a truly free compiler
by
mvw
·
· Score: 2
I agree with you.
Although a decent C++ compiler will take about 10 man years to finish.
Plus C++ Standard library.
Plus linker, assembler and debugger.
On the other hand if one doesn't start with it, it probably won't take off ever.
Anyone mad enough and seriously interested in that task should drop me a mail.
Regards,
Marc
Re:BSDs should develop a truly free CVS equivalent
by
Brett+Glass
·
· Score: 2, Interesting
Given GCC's extensive use to compile BSD licencsed code, getting rid [of] GCC should be a higher priority issue.
I don't disagree. GCC also poses another threat: it is wiping out virtually all alternatives. A monoculture is not a good thing, and so for this reason alone a BSD-licensed alternative should be developed.
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 finally had it: until slashdot gets article moderation, I am not coming back.
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
I write a blog now, you should be afraid.
cvsup -L 2 -g supfile
does the trick on my system.
The -g switch disables the GUI.
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.
Mea navis aericumbens anguillis abundat
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, 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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
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:
Credits
This incarnation of rsleep was first implemented by MSG.Net in 1994 as a 'ksh' script.
I do not deploy Linux. Ever.
I agree with you.
Although a decent C++ compiler will take about 10 man years to finish.
Plus C++ Standard library.
Plus linker, assembler and debugger.
On the other hand if one doesn't start with it, it probably won't take off ever.
Anyone mad enough and seriously interested in that task should drop me a mail.
Regards,
Marc
I don't disagree. GCC also poses another threat: it is wiping out virtually all alternatives. A monoculture is not a good thing, and so for this reason alone a BSD-licensed alternative should be developed.
The CVSup GUI was really more of a debugging tool than something that was supposed to be useful. Ask Polstra.
marotti.com