Slashdot Mirror

Michael Pyne writes "It's official, after weeks of preparation, KDE has completed switching their source control repository from CVS to Subversion. KDE is one of the largest software projects to make the switch, and is the first major desktop environment to do so. Some of the goodies that CVS users are used to are still in the process of being switched over (including WebSVN), but everything seems to be working well so far." (The announcement of early April is no longer the operative statement.)

thequbemaster writes "The OpenBSD project, responsible for OpenSSH, OpenBGPD, and OpenNTPD, has created OpenCVS, a BSD licensed implementation of CVS client and server. From the site: 'It aims to be as compatible as possible with other CVS implementations, except when particular features reduce the overall security of the system. The OpenCVS project was started after discussions regarding the latest GNU CVS vulnerabilities that came out. Although CVS is widely used, its development has been mostly stagnant in the last years and many security issues have popped up, both in the implementation and in the mechanisms.' No releases are available yet. The README in the OpenCVS CVS repository states that the server is not ready yet, but looks like the client is usable." Update: 12/15 20:18 GMT by T : This project was mentioned briefly the other day, too.

Simon P. Chappell writes "The Eclipse IDE has thundered into the collective consciousness of Java developers since its release by IBM as Open Source Software. Up until this time, the majority of available documentation at the Eclipse website has been for plug-in developers, with scant attention given to the rest of us that actually want to use the tool for anything else. This book restores the balance and brings much needed help to those interested in this IDE." Read on for the rest of Simon's review, about which he says "Full Disclosure: I received a free, review copy of this book, so feel free to assume that I've been bought off and have traded my technical integrity to put about an inch of dead tree on my shelf." Eclipse in Action author Gallardo, Burnette and McGovern pages 383 (15 page index) publisher Manning rating 8 reviewer Simon P. Chappell ISBN 1930110960 summary A good book that lives up to its name.

Overview With a book like this it's difficult to know where to pitch the level. Do you aim for the lowest common denominator or do you assume some experience on the part of your reader? This book seems to have pitched itself well, not pandering to the absolute Java newbie, not afraid to get down into the code and yet gentle enough that newer Java developers can follow easily. The heavyweight chapter on writing plug-ins is at the back where it shouldn't frighten those of a sensitive nature.

The book is divided into two sections. The first and largest section concerns actual use of Eclipse during Java application development. The second section is for those who wish to write plug-ins for Eclipse.

The book takes a very 'Test Driven Development' approach to Java development and this shows in the manner that Eclipse is presented and taught. Emphasis is given to the tools that come with Eclipse, especially Ant, Junit and the CVS client. For those already skilled in these tools, this might seem like filler, but remember that there are still pitifully few Java developers using even these simple and free tools. My hat is off to the authors for their TDD evangelism, skillfully disguised as Eclipse usage instruction.

What's To Like I liked the progression followed in the book, first teaching the basic operation of Eclipse and then moving on to the tools that come with the base install. What's To Consider Some may consider that the material on Ant, Junit and CVS is filler. The 'Test Driven Development' theme may be a little too much evangelism for some.

I use Eclipse on a Mac OS X box and I felt that there was very little discussion concerning the cross-platform attributes of the tool. All of the screenshots were from a Microsoft Windows build of the software; a Linux or OS X screenshot would have been helpful.

One more niggle and then I'm done. There is no information on using Eclipse with other programming languages (a couple of paragraphs in the introduction chapter doesn't really count). I've recently started tinkering with Ruby and have used a Ruby plug-in to allow me to work within Eclipse as I learn the language. This is a wonderful testament to the power and extensibility of Eclipse.

Summary This is a good book. You know it's a good book when you already use the tool (both pure Eclipse and IBM's WSAD) regularly and you find yourself learning things that you had not previously been aware of. If you are working with Java and want a good free IDE that's going to grow with you, then Eclipse is a tool you should try -- and consider this book the User's Guide that would have been in the box if Eclipse came shrink-wrapped.

Table Of Contents

1. Using Eclipse
2. 1. Overview
   2. Getting started with the Eclipse Workbench
   3. The Java development cycle: test, code, repeat
   4. Working with source code in eclipse
   5. Building with Ant
   6. Source control with CVS
   7. Web development tools
3. Extending Eclipse
4. 1. Introduction to Eclipse plug-ins
   2. Working with plug-ins in Eclipse

You can purchase Eclipse in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

MetalShard asks: "While building Pocket War we started using CVS and found it to be the best version control system any of us have ever used. We are also using Code Historian which works with CVS and lets you analyze the changes you have made in you code, and TortoiseCVS which adds an easy to use front end to CVS. It seems like there are a lot of cool add-ons for CVS, but we have not found a good CVS server configuration program. Is there one?"

parasew asks: "I am searching for Web-based Project Management Software, which should be (mod-)perl based, so I can enhance it or put it into an existing environment using MovableType, which is in a sort of alpha-state. I found a site about Call Center, Bug Tracking and Project Management Tools for Linux and also this short listing, but sadly they are just a bunch of projects which only come close to the kind of tool I am searching for. Gantt and Chronos, seem to be a very nice Web-Calendar packages written in Perl. I was just wondering why no one is using iCalendar (does anyone know of Perl-based Software using iCalendar), as most of the Agenda Software uses iCalendar, and even Mozilla Calendar is capable of subscribing to remote-Calendars. This looks very interesting to me. In general, I wanted to ask you Monks for the best way to do this. Should I create a new app from scratch or reusing existing stuff?"

"Here are the features I am looking for:

• The use of Calendars (multiple users) and iCalendar Support
• File-Pool for projects (CVS-based or similar)
• Progress-bar for showing the current state of a project
• A public calendar where users can publish events from their private calendars

I found a simple Calendar script from PerlMonks, and another easy one here. Of course, there are really lots of Calendar scripts out there, but I am asking you for hints. Which ones do you know of that comes close to my needs? There are several existing Modules for iCalendar on CPAN, and i thought about reusing stuff to maybe create a dirty hack of Chronos, Bricolage and add the CVS and iCalendar support on my own.

Please also see my topics on PerlMonks and MovableType

Thanks for any help, hints or suggestions."

RenHoek writes "Security expert Stefan Esser from E-matters discovered a bug in CVS version 1.11.4 and lower, that can give malignant users remote root access. The exploit was confirmed on BSD, but other OS's like Linux, Solaris and Windows are vulnerable too. A security advisory can be found here and there is also a patch available. CVS version 1.11.5 which is fixed can be downloaded as well."

RenHoek writes "Security expert Stefan Esser from E-matters discovered a bug in CVS version 1.11.4 and lower, that can give malignant users remote root access. The exploit was confirmed on BSD, but other OS's like Linux, Solaris and Windows are vulnerable too. A security advisory can be found here and there is also a patch available. CVS version 1.11.5 which is fixed can be downloaded as well."

An Anonymous Coward queries: "I work on a fairly large-sized project with at least a dozen developers. Advanced tools like CVS and ClearCase allow concurrent development, and provide merging tools to merge in different changes to the same file. This can be a significant productivity gain, particularly with files that are unavoidably common to several developers (C header files, most notoriously). During crunch times, such as before delivery deadlines, we often find that we are checking in changes to the same file several times a day, often hourly. The problem does not seem to be with conflicting changes to the same lines of code, but rather with developers knowing the sequence in which concurrent changes will be checked in. It is not possible to always be aware of who is checking in what and when, so programmers submitting patches to the baseline often have to redo those patches multiple times in a day in order to have them applied. Have other programming projects developed solutions for dealing with this problem?" The submitter proposes another solution, below, how well would it work?

"Take, for example, the extreme case of something like Linux (not only concurrent development, but geographically distributed development), how is this managed? One solution we were contemplating was to try to do an 'air traffic control' type of sequencing and conflict resolution. As early as possible in the development stage, we try to identify what will be finished when, and assign a one-up sequence number to each patch. Developers then know that they will be patching against the baseline that was patched by the patch with the previous sequence number. It is hoped that this prevents a lot of rework of patches. A potential problem with this approach is the need for a responsive central authority to assign sequence numbers. Also, such sequence numbers may have to be rearranged in the face of last minute advances and setbacks in developer progress. Despite careful scheduling and detailed design, it may be impossible to know the exact check-in sequence of patches more than a week or two in advance.

Will such an idea be successful, or is it fatally flawed? Are there better solutions to the problem with less effort? Are we treating symptoms and not the disease (i.e., should we be planning better so that we know patch sequences and dependencies early on)? Management likes to keep staff productively occupied and working up until deadlines, so this usually means a lot of checkins within a short period of time, rather than staged checkins. Can checkins be spread out over time while keeping developers productively occupied?"

CodeNation asks: "I'm a coder in smallish (~50 staff) company with a ~20 strong development team. We, the development team, have been using CVS, and CVSWeb to manage our source base for a couple of years. In the meantime, our corporate documentation has become a complete mess. By 'corporate documentation' I mean content such as Word documents, Powerpoint presenations, and Excel spreadsheets. Anyway, I was recently asked by the one of the bosses to put a document version control system in place for this corporate documentation. All this, and the system has to be usable by the non-technical." Ask Slashdot has touched on a similar topic but it's been about 2 years since that article. Has there been any headway in this area?

"Now, this would be a trivial task if:

• The documents were text-based (i.e. the file formats weren't binary)
• The entire company understood how to use CVS

However, neither of the above are true.

I took a look at CVSWebEdit, but unfortunately it's not quite there yet in terms of stability and usability.

Does anyone have any suggestions for a possible solution? What are you currently using for document control (remember these are Microsoft Office documents). Also note that although the developement team works on Linux boxen, the non-technical staff works in a Windows environment.

Thanks for your help."

On-the-fly organization may suffice for keeping track of scripts /bin on your local machine, but larger projects have more at stake when it comes to coordinating the effort of programmers, especially when they're not even in the same timezone, never mind in the same room. CVS has become the lifeblood of many such projects. Reader Craig Pfeifer suggests CVS Pocket Reference as a good way to help keep that lifeblood flowing.

CVS Pocket Reference author Gregor N. Purdy pages 75 publisher O'Reilly & Associates rating 8 reviewer Craig Pfeifer ISBN 0596000030 summary Indispensable handbook for administrators of all but small CVS installations, and probably for the small ones as well.

The Scenario

As a former CVS repository administrator, I wish I had this book when I started, it's much easier than pawing through the canonical documentation for quick answers. CVS is the #1 choice for open source projects. If you plan on organizing or working on an Open Source project, this is reference might be for you.

What's Good?

This pocket reference is a guide to basic CVS functions (branch, merge, update) but the real strength is in the description of server and client side control files and environment variables. Gregor describes how to setup email notification when someone commits a change to the repository, how to customize the repository to treat certain files as binary (versus text), and other useful things. He even goes as far as to describe how to hack the repository to change it's structure while the project is in motion, and how to hack the sandbox (the name for a developer's work space) to change any property such as which branch or repository the files will be committed to. Of course you don't really need this because developers never make mistakes, it's always CVS' fault &ltwink wink&gt. All in all, it's a great reference for all the bits and pieces of CVS that you're supposed to mess with (and a few your aren't) and anyone who is expected to administer a moderately complex installation should own it.

Gregor also gives pointers to some great add-on modules for CVS: CVSWeb for making your source tree web-browsable, and WinCVS to make CVS look SourceSafe-esque.

What's Bad?

The organization of this pocket reference could use a little help. I've seen reviews for other O'Reilly pocket references ask for an index, but that wouldn't be helpful here. It would be helpful if they added section tabs in the outside margins of the pages (a la their java nutshell series), so that you could quickly thumb to the section you're looking for. Also, organizing the content by server side and client side instead of simply adminstrator and user would help folks to find the specific information they are looking for.

My last gripe is a small, petty one. The books binding doesn't allow it lay flat when you set it down. Yes it's petty, but I hate losing my page when working. You need to keep a medium sized object with a decent bit of heft (e.g. a stapler) within arms' reach to hold it open.

So What's In It For Me?

This reference will not make you a CVS guru, but it will help you remember the command line options (if I had a nickel for every time I typed 'cvs --help tag' I would be frequently mistaken for a Kennedy), figure out what all those little files are without breaking your CVS installation, and most importantly keep you from having to consult the the cannonical documentation for simple things.

If you have inheirited a CVS installation or plan to set one up for the first time, spend the US$9.95/CN$14.95, do it right the first time and save yourself some time and reap all the bennies that CVS offers.

Table of Contents

1. Introduction
2. Installing CVS
3. Administrator Reference
4. User Reference
5. Relata

You can purchase this book at ThinkGeek.

On-the-fly organization may suffice for keeping track of scripts /bin on your local machine, but larger projects have more at stake when it comes to coordinating the effort of programmers, especially when they're not even in the same timezone, never mind in the same room. CVS has become the lifeblood of many such projects. Reader Craig Pfeifer suggests CVS Pocket Reference as a good way to help keep that lifeblood flowing.

CVS Pocket Reference author Gregor N. Purdy pages 75 publisher O'Reilly & Associates rating 8 reviewer Craig Pfeifer ISBN 0596000030 summary Indispensable handbook for administrators of all but small CVS installations, and probably for the small ones as well.

The Scenario

As a former CVS repository administrator, I wish I had this book when I started, it's much easier than pawing through the canonical documentation for quick answers. CVS is the #1 choice for open source projects. If you plan on organizing or working on an Open Source project, this is reference might be for you.

What's Good?

This pocket reference is a guide to basic CVS functions (branch, merge, update) but the real strength is in the description of server and client side control files and environment variables. Gregor describes how to setup email notification when someone commits a change to the repository, how to customize the repository to treat certain files as binary (versus text), and other useful things. He even goes as far as to describe how to hack the repository to change it's structure while the project is in motion, and how to hack the sandbox (the name for a developer's work space) to change any property such as which branch or repository the files will be committed to. Of course you don't really need this because developers never make mistakes, it's always CVS' fault &ltwink wink&gt. All in all, it's a great reference for all the bits and pieces of CVS that you're supposed to mess with (and a few your aren't) and anyone who is expected to administer a moderately complex installation should own it.

Gregor also gives pointers to some great add-on modules for CVS: CVSWeb for making your source tree web-browsable, and WinCVS to make CVS look SourceSafe-esque.

What's Bad?

The organization of this pocket reference could use a little help. I've seen reviews for other O'Reilly pocket references ask for an index, but that wouldn't be helpful here. It would be helpful if they added section tabs in the outside margins of the pages (a la their java nutshell series), so that you could quickly thumb to the section you're looking for. Also, organizing the content by server side and client side instead of simply adminstrator and user would help folks to find the specific information they are looking for.

My last gripe is a small, petty one. The books binding doesn't allow it lay flat when you set it down. Yes it's petty, but I hate losing my page when working. You need to keep a medium sized object with a decent bit of heft (e.g. a stapler) within arms' reach to hold it open.

So What's In It For Me?

This reference will not make you a CVS guru, but it will help you remember the command line options (if I had a nickel for every time I typed 'cvs --help tag' I would be frequently mistaken for a Kennedy), figure out what all those little files are without breaking your CVS installation, and most importantly keep you from having to consult the the cannonical documentation for simple things.

If you have inheirited a CVS installation or plan to set one up for the first time, spend the US$9.95/CN$14.95, do it right the first time and save yourself some time and reap all the bennies that CVS offers.

Table of Contents

1. Introduction
2. Installing CVS
3. Administrator Reference
4. User Reference
5. Relata

You can purchase this book at ThinkGeek.

briany asks: "I have been asked to evaluate Clearcase vs. CVS. I am wondering what kind of experiences people have had (good and bad) with either product, or if there are other products that should be considered. The projects that will be stored are rather large (10+ GB) and need to be accessible from Solaris, Linux, and NT/Win2k." Of course, it should be mentioned that Clearcase is available for Linux, as well as other unix clones.

slamdaddy asks: "At my previous place of employment we used CVS's tagging features to move files from the repository to the staging and production environments. I had assumed that they just attached a script to a certain tag (i.e. the tag "ALPHA" sent it to the common dev environment, the tag "BETA" sent it to the QA environment and the tag "LIVE" sent it to the production/staging environment) and the script just ran whenever you tagged a file with the appropriate tag. I've been looking through the CVS documentation at www.cvshome.org and have not found any facility for this. To answer this, I did a search on Google and came up with Nik Clayton's excellent series titled Managing websites with Unix" on DaemonNews. It looks like part five was going to cover everything I need BUT... it was slated to come out in May and never appeared on the site! Are there any other resources that explain how I can use CVS tags to copy the HTML pages to the proper locations?"