Slashdot Mirror

See http://www.cvshome.org/docs/manual/cvs-1.11.20/cvs _18.html#SEC159 for details

For instance we share code across products via the CVS "modules" file:

p1 m1 &m100 &m101 &m102 &m103 &m104
p2 m2 &m100 &m101 &m102 &m103 &m104
p3 m3 &m100 &m101 &m102 &m103 &m104

This is about the only real thing holding us back from switching over.

because CVS is GPL and available for a lot of platforms... and guess what?? you can use it with that old 486 system that you have in that corner...

because CVS is GPL and available for a lot of platforms... and guess what?? you can use it with that old 486 system that you have in that corner...

The thing that burns me about cvs is the lack of proper handling of branches & dates at the same time for cvs updates and diffs:
Here is more info
That alone is good enough for me to switch to subversion, but I've found the switch to subversion (pre ffs) really problematic and so s-l-o-w (almost unusable) via the apache module.
--jeff++

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

http://www.cvshome.org

1. What if at the end of the day you forget to do a tarball?
2. What do you do when you want to find a change to a file and you're currently on project-3.216.197 and you're not sure when or why you changed foo.c's logic and you want to change it back but you don't know what you're going to break in the process? I use cvs log. What do you do? Open up hundreds of tarballs trying to find your one silly change? I know you said you don't look at old code, but that's probably because it's too tedious for you to examine all the tarballs.

The benefits are too numerous to list. Read the Cederqvist. It's not very long, and you can decide for yourself if you want it. Basically, it's good for when shit goes wrong (helps answer the question of where, when, and why), when you want to experiment (create a branch... what do you do when you want to experiment? Make two nightly tarballs?), collaborate (I know you said you work alone, but that will not always be the case hopefully), and many more.

Cederqvist, the "official" manual, is surprisingly well-written, and worked wonders teaching me about CVS. Highly recommended, and available for free in a variety of formats at the CVS web site.

Hm. Well, maybe. There have been a couple releases this year, and the mailing list remains active.

I kind of feel that the torch is being passed on to Subversion, with no hard feelings between anyone. Lots of folks are converting over and most folks seem pretty happy with it. But CVS is still widely used and there are a bunch of of gurus who hang out on the list and answer questions.

Oh, and here's a mirror of various CVS releases if anyone needs them.

Heh - I did that with a CVS card (CVS is a drug store in this case, not the versioning system). Every time I use it, my receipt reminds me that my information is "incomplete" and tells me to go to their webpage and update the account.

What works really well is to try and take advantage of a loyalty-card holder sale and act rushed. So they'll give you the card and tell you to give them the application later. Just never hand in the application, and you're all set. :)

(Of course, in my case, it's not that I'm paranoid, it's that I don't want the ****ing advertising "newsletter subscription" that comes with the card.)

You forgot to mention CVS (http://www.cvshome.org/). Usually database developers commit their changes to their stored procedures directly into the only database, where they are stored. That is not good, because other Java developers are using the same database at the same time, so they see intermittent bugs.

It is better if all code goes into CVS, even stored procedures. Not to mention that every developer must have a copy of the database in their own machine, usually MySql (http://www.mysql.com/) or HSQL (http://hsqldb.sourceforge.net/) is better for that.

Then from CVS you take out a build (you use CruiseControl to generated builds that are compiled and unit tested using JUnit http://www.junit.org/) so you know all the Java code works with the stored procedures, the database model and the example data. Then you can add your code, with your unit tests, into CVS.

My $0.02 CLP (= $0.0000318238 USD according to http://www.xe.com/ucc/)

We use CVS for the primary repository, and Perforce for an extra repository with a gazillion branches where a lot of the larger projects are done.

The primary reasons we use CVS is (A) habit (it was the only relevant alternative when we started), and (B) The distribution architecture we have for it (cvsup).

Given that we use cvsup as one of our primary methods of distributing continous updates, we would have to re-train about a million users (guesstimate). We also have thousands of developers that are familiar with CVS, these would also need re-training.

Those of us that has looked carefully at the version control/configuration management issues believe we are taking a continous and fairly high cost from CVS. We are probably going to do the switch at some point, but before we do, the relevant infrastructure needs to be in place (distribution of repository copies and checkout a la cvsup is probably the most important), and we should get something with all of the features we need, so we don't have to do one more switch.

The most important that we presently lack are cheap branching, distributed branching (being able to create a branch that only exists in a mirrored repository), and idempotent merges (the same change can be merged through several branches and only enter the system once). Tracking directory metadata and helping with renames etc would be nice, but isn't that important for FreeBSD. (I believe this to be more important than the other shortcomings of CVS for smaller projects, BTW).

A final interesting thought: I believe that the sharp distinction between NetBSD, OpenBSD, FreeBSD, and DragonflyBSD is a result of the lack of distributed branching and easy merging. The personality issues and different goals are there, of course, but I believe these would have been "overrun" with the ability to easily move changes back and forth. The single issue that has resulted in the "deep" splits is the effort involved in moving changes.

Eivind.

The second way is known as "local" or "non-client/server" CVS. This lets you run CVS if you have only Windows machines. However, due to issues (a) with local CVS on Windows, and (b) with the suitability of Windows as a server operating system in general, we would generally recommend this more to try out CVS and get a feel for it rather than for production use.

CVS (Concurrent Versioning System) is definitely the way to go.

Here are some links to get you started:

CVS On Windows

WinCVS GUI (very nice, uses Python undeneath)

Tortoise CVS

CVS NT Wiki

Component CVS for Windows

All of these are CVS for Windows tools. CVS is a great revision control system.

I would recommend using CVS and CVSTrac. They both work fine under Windows (as servers). CVSTrac also gives you the benefit of browsing the code from the web, a bug tracker and a Wiki.

I hope that instead of a save button, some programs will constantly save work and provide a timeline-like feature to go through all changes in the document if neccessary.

I use vim and RCS for this purpose.

RCS allows me to check in and out revisions, and each revision has a change log. I can roll back changes, check differences, and even make my own branch of a file.

Subversion, CVS, Arch and many others also can fill the same role. Heck, you can even make a directory named backup and rename a copy of the file to 'myfile_date'. The reason why I settled on RCS is that its relatively simple to use and its cross platform (Linux, BSD, Windows-via-Cygwin, etc). I've been tempted to adopt one of the larger revision control systems for additional features, but haven't gotten around to it.

As for Vim, its cross platform, rather full featured, and if the power goes out, I still can recover the file. Plus its easy to use with RCS through a few simple aliases and/or keymaps. There is also Gnu Emacs or XEmacs and a host of other good text editors.

Sure, there could be one program that would do both, but that wouldn't be as useful. The unix philosophy of "do one thing, and do it well" is less of a pain in the long run. This way, I can reuse my $editor_of_choice in many other unix applications - slrn, mutt, etc. If I had one integrated program, sooner or later I'd become fed up with one part of it or another, and I would be forced to continue using it.

Just my $.02.

YMMV.

And how do you plan to manage those OpenBSD (or whatever) boxes evenly distributed around the globe?

Wow, there are certainly no tools at all that I could think of that would help me do that...

To quote one of my favorite legendary assholes: "This is unix. Stop acting so helpless."

(In all seriousness: yes, there are probably plenty of cases where there's no business case to be made for rolling your own system, and where Checkpoint's management console or a similar tool is probably a good choice.)

What if you add VPN to the soup?

Using Checkpoint? I'd say that you now have a pressing need for an aspirin. YMMV.

Here's the overview from the manual.

The market is currently quite rough, especially to break into. After being laid off when a product tanked on the market, I've gone a few months without having a single resume responded to - and I have almost a decade of professional programming experience that was applicable to the jobs I've applied for (and my resume used to keep the phones ringing daily for months when I posted it - the market has changed a bit).

I've been spending the extra time continuing development on my personal code library and projects, writing open source code, and working on a few products that I expect there to be a market for when they're done. That's how I'd suggest breaking into the field as well.

You have a very special situation though - you know, or can find out if you think about it and ask your colleagues, exactly what one fairly wealthy niche market needs. What software would help you - as a doctor - work more efficiently? What software have you and your colleagues found lacking? There's your first project :)

It won't be easy, and you won't make money fast. My recommendation would be to start learning about computers and computer programming now while thinking about products. As soon as you feel like you can design a useful program and have one in mind - take a shot at it.

Use CVS ( or for Windows, WinCVS ) or some other revision control so you can keep track of all the code you write (I wish I had when I started!). Estimate for yourself how long tasks should take - track those estimates, and figure out why they were right or wrong. Document everything, especially the code.

Once you have a product you think is worthy for your target audience - use it yourself in your work. Then let some colleagues try it out. Fix anything you find wrong with it, and ask your colleagues for suggestions.

Then, set up a website, advertise it, and try to sell it - or set up a project on SourceForge and make it open source - whichever you feel more comfortable with. On SourceForge, you'll be able to enlist the help of other more experienced programmers and together tailor the product towards excellence. If you sell it and it's successful, you'll be able to afford to switch careers to full-time programmer/entreprenuer and just work on your business.

That brings me to another point - if you aren't currently running your own doctor's office, start learning business skills too. They're just as hard to pick up as programming skills - possibly harder for some. Figure out what you'll need to do to start running your own software company. Even if you decide to write your own software as open source and become an employee for someone else professionally, this will help you at the negotiating table.

What I would NOT recommend is dropping out of medicine, getting a BS in computer science, and expect doors to be immediately open when you g

Looks like your are right about that being a CVS version header (Google Search - but that doesn't mean right off its from a Linux user. CVS does support Windows - well to some extent.

The BSDs all keep the system under revision control; all the free BSDs use CVS. Revision control (in extremely brief) is a process by which editing a program means checking out a file or group of files, making the changes, then checking in the new versions, along with a message describing the change. A full history of all changes is kept in the revision control system, so you can view a history of the changes, check out an old version, look at the differences between arbitrary versions, etc.

All the BSDs provide public access to their CVS repositories in one way or another; generally through anonymous CVS, or CVSup checkout or mirroring, or often both. That means that, as a user, you can see exactly what changes happened when, who did them, and why they did them. You can also always get your hands on the latest changes (within a few hours, anyway, depending on mirroring strategies). All of the free BSDs have mailing lists that you can subscribe to and see the changes as they're made. In fact, they all have web frontends as well; you can poke around FreeBSD's entire source tree online at http://cvsweb.freebsd.org/src/, and see all the history of every file.

Linux, historically, hasn't used any version control for the kernel. I don't have exact data at my fingertips here, but I believe it was somewhere in mid-2.4 days that the kernel began being kept in a public BitKeeper repository. Many of the other utilities use revision control, but since they're all developed separately, there isn't any central place you can go to to look through the changes. So it's sometimes hard to get a historic picture of even any one part; to so do for a whole distribution is practically impossible.

This leads to a lot of differences. In a very real sense, BSD systems are constantly developed; I can always update my system to the absolute latest code, irrespective of "releases". In Linux, that doesn't really have as much meaning, because the release process is very different. I think the most appropriate verb for a Linux release is "assembled". A Linux release is assembled from version A.B of this program, plus version C.D of this program, plus version E.F of this program... all together with version X.Y.Z of the Linux kernel. In BSD, however, since the pieces are all developed together, the verb "cut" makes a lot more sense; a release is "cut" at a certain time.

Linux releases kernels in two parallel lines (well, often more than 2, but we're simplifying); a version with an odd minor release number, as a "development" version, and a version with an even minor release number, as a "production" version. The BSDs also have "development" and "production" tracks, but they're handled rather differently.

CVS, like most version control systems, has the concept of "branches". It's easy to understand, but somewhat difficult to explain. Basically, when you "branch" a file or a set of files (or a whole directory tree), you create a new version of the file which exists in parallel with the primary version. When you make changes to the primary version, it doesn't affect the branched version. And you can make changes to the branched version without affecting the primary.

In FreeBSD, there's usually 2 active development lines; one called "-CURRENT", which is the development version, and the other called "-STABLE", which is the production version. Both, of course, are under development, and both have some attempt to be made to keep them usable. -STABLE, as a rule, gets bug and security fixes, but only gets new features and such that are well tested, usually by a stint in -CURRENT first. -CURRENT gets new features, big architectural changes, and all those sorts of new development stuff. It should be noted that the naming of the branches doesn't necessarily mean what it seems to; while -STABLE usually is "stable" as in

I am currently publishing several several-hundred-page technical manuals using the following workflow:

All documentation is edited using an ordinary plaintext editor.

The documents are marked-up using ReStructured Text conventions. This has satisfied 99% of my needs. I've decided the convenience of ReST outweighs the need for the remaining 1% of the frills I want.

I use CVS for revision control. There may be an RCS involved in the backend; I don't operate the server that hosts my repository.

The ReST documents are converted to XML using DocUtils. The project coordinator, by the way, has proven himself a superlative programmer. DocUtils rocks, and will also transform ReST to HTML or Latex.

The XML is converted using XSL templates that I've created. Saxon then transforms the DocUtils XML to XML:FO, and FOP transforms that into PDF.

Pretty fucking spiffy, if I do say so myself.

I also currently use HT2HTML to transform ReST to HTML. I use it in preference to DocUtil's native HTML transformation because it allows me to do a few nice tricks. In the future I plan to migrate entirely to another set of custom XSL tranformations.

This system has proven extremely productive. At any time I could pop a few bucks for a commercial XSL:FO->PDF engine and stomp the few gripes I've had with FOP (my number one issue is lack of keep-with-next functionality; however, FOP is under a complete refactoring, and will emerge with full functionality). Saxon has been superb, DocUtils has been wonderful (and I've been able to contribute to the overall design), and ReST is quite pleasant to read and write.

Overall, I highly recommend this workflow.

Your source material becomes extremely reusable, eminently accessible, and free from commercial encumberances.

(footnote: if you do go this route, please don't flood the DocUtils developers with suggestions and ideas. Work out your idea in detail, consult the developers' mailing list archives, and make full consideration of side-effects. Only then suggest it. They've been at this so long, and had so many discussions, that they've become a little short of patience with loud-mouthed newbies. I suspect most popular open-source projects get that way...)

TeXinfo

texi2html

If you don't have those tools in place at your company, and you want to telecommute - I'd suggest putting them in place *first*, getting everyone using them, then try asking your boss. You can point out, at that point, that the communication is the same either way. Otherwise, standard telecommuting really does hurt teams if they can't communicate as well.

Learn to use cvs, it allows you to keep up with the "new features" at the cost of stabilty.

Read this this and this.

The CVS version of kde is way ahead of gnome, it's just that it's not up to alpha quality yet.

CVS is a system specifically designed to (among many other things) keep text files in sync across multiple machines. It can handle binary files also, but not particularly well. If you have a system in which you can set up a CVS server (all the tools are built into Mac OS X + Development Tools) I recommend experimenting with that.

The iCal calendar files are text files that could be synchronized. Note that I have *not* tested how well this would actually work with iCal.

The Apple Address Book application does not seem to store its address books as text files, so CVS is less likely to work well with it. But Eudora seems to store its address books as text files.

cvshome.org

I have considered doing this myself, as my first annual .Mac membership nears renewal time.

Search enterprise linux.com has a four part series on open source support that might help.

For well known software just call it "industry standard software". This would include things like EMACS, CVS, GNUmake, gcc, Apache. Tell the management you would suggest using the Industry Standard Apache web server, or the Industry standard revision control tool CVS.

You could list examples of companies that use these tools already. You can get some examples of current corporate users at the home pages, or by e-mailing the support team. Concentrate on listing Fortune 500 companies, your company's competitors, and well regarded high tech companies.

Good Luck in your effort!

However, those are largely things we don't control. The controllable factors of success are more interesting to me. I guess it's because there are lessons on software engineering here. Cool projects can be run into the ground, and tiny niche projects can do well if they're well-run.

Hands down, the best nuts-n-bolts coverage I've ever seen on important issues to successfully developing open source is in a book by Karl Fogel, Open Source Development with CVS. Fogel's one of the developers behind CVS and it's planned successor, Subversion

The book is an interesting paradox: it has 1/2 the chapters GPL'ed. When I started working with CVS, they were useful enough that I bought our development team two copies of the book. Then I read the rest of it... and those are the chapters I'm talking about. Absolutely, they're the best summary of what it takes to successfully run a GPL-ish project. (Ironically, they've GPL'd the technical detail chapters and you have to buy the book to read the parts that talk about things critical to the success of an open source project).

Success is helped by things like doing lots of releases (seeing progress gets others to buy in, and not seeing progress leads to people quitting in frustration) and only adding features you need (let someone else add the features they need). There's a lot more here, but I'm not about to steal Fogel's thunder. Many of these are ideas that are effective in regular development, especially on custom coding projects within big companies.

The focus on GPL code is not the same as on shrinkwrapped products: you're not trying to add features just to add selling points. You're trying to get more people to use the project.

What to replace it with? At home and at work I use CVS. Sure, CVS has lots of problems, but at least they're well known problems with easy workarounds. At its core CVS is solid, if dated, software. There are other products I've heard good things about other packages, but I lack the experience with them to judge them. What I do know is that CVS is far and away superior to SourceSafe.

PVCS - My software company migrated from MS VSS to PVCS, it works much better - but - at least for our relatively large project, it's kind of slow. We've been using it for about a year and it's worked well.
Clearcase - Rumored to be "THE version control system", I've heard it is complicated to setup and use, but Rational Clearcase is supposed to be the end all of version control systems. Checking out the link before posting, it seems that Rational software is now owned by IBM?
Starteam - I evaluated this product a while ago (18-24 months or so ago). It seems that this company has been purchased by Borland. But at any rate, Starteam seemed to be a very comprehensive version control system. We didn't choose Starteam - as many of our developers had already had PVCS experience and at the time Starteam was the new-kid-on-the-block and we didn't want to fight with a new product. We already had enough headaches with MS VSS, we wanted something we knew for certain would be tried and true. That being said, Starteam did look great.
Last but not least, CVS the open source version control system. I've used it a few times, but never set it up or configured it and can't really comment on reliability, etc. I'll assume it's great - I'm know others have mentioned CVS and I'll leave the people that have used it to give you more information.

Sounds a hell of a lot like CVS + Apache + CVSWeb.

They say they are using a new source code control system with "acquired technology" , apparently because the previous version (which I'm assuming is SourceSafe) wasn't up to the task. I'd like more details please ... we are considering ditching a very old version of PVCS where I work. Bitkeeper won't do it, and CVS + Bugzilla isn't a solution.

You cannot say that the club is unbiased - but you do not know that the club is biased either. This is not because it straddles some ambiguous nether-region. It is because you know nothing of the club beyond what you have heard or read. (Come visit sometime, the pizza is for non-members too!)

At the foundation of the club is a set of values that supercedes any corporate affiliation. At the core is the desire to learn about technologies that we are not exposed to in course material, yet may encounter in the business world.

Since Ohio State students are likely to graduate without meaningful technical exposure to Microsoft products, this is often the logical choice when looking for a solution to explore. Undoubtedly we can fall back on the assumption that if we choose a Microsoft solution it will be provided to us free of charge, but this does not drive our selection process as much as an outsider might imagine.

In a recent discussion on source control there were over 60 discussion posts over the course of two days - largely debating the merits of CVS vs. VSS. Ultimately we elected to set them both up and conduct an analytical study of the merits of each. If anything, as with society at large, I've noticed a subtle anti-MS bias among club members.

Later in your post you complain about a professor of yours whom you feel is being tempted by the beast.

You then comment on his apparently poor administration skills (only negligent admins were hit by the SQL worm). Maybe he's still learning?

You also use the term "allegedly" to describe your lack of knowledge regarding the financing behind the lab in question. I suspect that in your unbiased comments regarding the many Unix, Solaris and Mac labs in campus, you replace "allegedly" with "generously" when describing how financing for these labs were secured?

Perplexed at how an instructor might achieve impartiality given all of this bribery, you retreat to the rationalization that Java (with an 7 year head-start) development outpaces development in (1 year old) .NET. You sound like a boastful mother bragging that her son can read to the parent of an infant who still needs his diapers changed!

My point is that for someone who seems to continually lace his/her prose with subtle inferences to your distaste for MS, you're not a poster child for objectivity.

• Which IDE you want to use, ranging from Open Source $0 IDE to commercial ones.
• Which source control you want to use, ranging from Open Source $0 source control to commercial ones.
• Which middle tier implementation you want to use, ranging from Open Source $0 application servers to commercial ones
• Which database you want to use, ranging from Open Source $0 databases to commercial ones.

In short, you choose J2EE in order to have a choice of what software you want to use within your business and how much you are willing to pay for it, what hardware (Intel, Sun, IBM) and operating systems (Linux, Windows, Solaris, AIX, OS/400) requirements you have, and what requirements you have on the performance (single Intel box to 64 CPU Sun box to IBM mainframe) and scalability of your application.

You make J2EE match your requirements rather than force yourself to match .NET requirements.

It will save you time and money because you won't end up buying/writing something you don't need. And you might be surprised how useful index cards can be...

PVCS or ClearCase or can set you back 5K a workstation.

If you're not using all of the features in these products, they can be replaced by CVS and something like SourceForge.

One that's also been around a while is Aegis. It was first released in 1991, so is not a newcomer to the scene.

I haven't used it personally, so I can't vouch for how well or poorly it works. I was looking into Source Code Control programs a while back and decided on good old CVS. Don't forget a GUI.

From the CVS manual:

(the release command)
This command is meant to safely cancel the effect of `cvs checkout'. Since CVS doesn't lock files

Locking files is very important in a normal work enviroment, and CVS approach is more towards "loose" free project development.

You are probably already doing this, but just in case... Make sure you have CVS setup to treat the flash files as binary.

I have that setup working on Win2K. What I did was this:

1. Get the cvs package for windows from www.cvshome.org and install it.

2. Make sure that the cvs exe is in the path (to make life easy).

3. Get the ssh client from www.ssh.com - its the windows workstation version, it comes with a command line version of ssh (ssh2). It is free for non-commerial use (flame away, it works without messing with cygwin, which is what counts for me)

4. Make sure the ssh in in the path (again, makes life easy)

5. Make sure you can connect to your remote server (if applicatable) with ssh either from the gui or the command line (ssh2). You can set up key pairs or other authentication for ssh so that you won't be prompted for the password (if any). See the docs for the ssh server & ssh client for more information.

6. Set the following environment variables:
CVSROOT=:ext:user@server:/reposity/pat h
CVS_RSH=ssh2

You should be good to go with the normal cvs command now (checkout, update, commit, etc). Test it out by checking out a module or two.

Note that this will not work for those repositories that use cvs's network abilities - for those you *might* be able to tunnel the connection over ssh, but only if the remote side is set up to handle those.

A good source of information for setting up cvs is here at www.cvshome.org

http://www.cvshome.org/

As we're all experts here, I should point out that content management seems to be just a new buzzword for boring old configuration management with bells and whistles on.

What you need is to combine VNC with a distributed (ie. multiple-computer, at multiple-locations, with multiple-ISPs on multiple-backbones) setup. I'm not aware of any automated products for this, what I've done in the past is to have an main CVS repository on one box, and a cron-job that updates it every night from a different machine. If you lose that main box, you'll have a worst-case day old copy of the repository on the other machine, and can still continue to do your work. If it's a big problem with several days of downtime, you can then set the backup as the main CVS server.

This could work for any number of "backup" computers, but even having two will pretty much eliminate the downtime you've suffered before. And you can use CVS to backup all sorts of stuff (code, IDE config files, even binary data).

In the *nix world, esp. if you're used to a command-prompt instead of a GUI, using VNC is often overkill - I tend to use an OpenSSH java applet (such as AppGate's excellent MindTerm), which can run over slow connections without issue, and can be served from any number of computers.

(However, for a Wintel solution, you'd have to find a configuration-management tool that can automatically update stuff for you - not sure if Source-Safe or StarTeam can do this).

Transposed letters in the URL. This is the link for CVS.

Alas it's not mentioned in the manpage. But you can have an overview here: http://www.cvshome.org/docs/ref.html

Now I'm confused!

I've been using CVS for years and read with great interest the recent Linux Journal article about the Subversion project to created a CVS replacement that is better than CVS.

Then I see a Slashdot story about arch.

Now, my FearLessLeader starts using Bitkeeper.

Should I move from CVS and, if so, which is best?

So here it goes...
What is your favorite revision system and why?
What is the URL?
Is it open source or proprietary?

emacs

autoconf

make

• CVSWeb
• Bonsai
• LXR
• TortoiseCVS