What CVS program do you use?

[NoodleKnight]

Hi,

I was searching around for a CVS server that would display through HTTP. My friend told me about SandWeb, but the whole assembly is complicated to install. I was wondering what CVS programs do you use? Is it viewable through HTTP (browser, as in you can access a website and use CVS on there).

Thanks

[evulish]

I don't use one myself, but I hear ViewCVS is popular. I'm pretty sure it's what sourceforge uses.

[HFWang]

Wait, are you saying some sort of web interface to CVS? Then, yah, second the ViewCVS comment.

Client side, I use tortoiseCVS or something like that.

[Brandon Martus]

Chora is a nice one. (demo)

At work we use cvsweb

[Tom Bottiglieri]

Well, I use the extra care card..

heh

[Alan Anderson]

For a version control program, TechnoKats traditionally use copy. We just make daily (or more frequent) duplicates of the folder full of source code.

If we had multiple people working on separate parts of a programming project, or if we had many projects to keep track of, I'd definitely pursue something more fancy. But with one or two people working on a single program, formal version control is essentially overkill.

[Dave Flowerday]

Originally Posted by Alan Anderson

But with one or two people working on a single program, formal version control is essentially overkill.

To each their own, of course, but I disagree. I use version control all the time on projects where I'm the only one working. Being able to create a branch for more "risky" changes, being able to quickly look at a tree of revisions and compare differences between each, tagging, and being able to look at check-in comments for each version are all so useful. You can of course do all these things with the "copy" method, but the version control tools just make each of these actions so much easier. Plus, in the event that you begin to have more people working on the project, then you're already set up to handle them.

Just out of curiousity, have you played around with using CVS or Subversion? You don't need a server or anything (you can just run it on a local machine, with the repository just being a directory). I know for me I used to use the "copy" method back in college and it seemed fine, but now that I've seen what version control could do I can't imagine how I got along without it

[Alan Anderson]

Originally Posted by Dave Flowerday

...I use version control all the time on projects where I'm the only one working.

Ah, but you're talking about managing multiple projects. I'm not.

Just out of curiousity, have you played around with using CVS or Subversion?

I use formal version control regularly. For my day job about fifteen years ago, I actually implemented a high-level version control and release/distribution system based on the old Polytron VCS tool with a database-connected wrapper. When you've got more than one program being worked on, a real version control tool helps a lot -- and when you're dealing with hundreds of programs, it becomes essential.

But when there is only one program being worked on, I'll stick with my opinion that it's unneccessary. Like the robot itself, the control software is a one-off thing with a very limited lifetime. Documentation and structure are always important, but as long as it's a single project under the control of one person (or two working closely together), formal change management is an added layer of complexity that only pays off in the very long term.

If we had several parallel development paths going on, or if we needed to maintain multiple years' worth of robot software, then I'd agree that a "real" VCS would be worth the minor extra complexity for each project. In fact, with the network and file server system we're about to put together for our team's use, we'll probably find ourselves wanting to manage multiple projects soon, and I'll embrace a formal version control system for that situation. Until then, however, I really don't think there's anything a CVS "check in" provides that a drag-and-drop "copy and rename" of the lone software folder doesn't give us. On the other hand, having separate folders for each day's work actually makes it easier to do offsite backups (on flash drive or floppy disk), and to use any random team's computer to do development in an emergency.

[Dave Flowerday]

Originally Posted by Alan Anderson

Like the robot itself, the control software is a one-off thing with a very limited lifetime.

Perhaps that's the difference in our approaches. We attempt to re-use software as much as possible from one year to the next, so we don't consider our software to have a very limited lifetime.

Until then, however, I really don't think there's anything a CVS "check in" provides that a drag-and-drop "copy and rename" of the lone software folder doesn't give us.

I agree. Like I said, you can accomplish the same things with your copy method. We just prefer the convenience and ease-of-use from a version control system.

Along these lines, another thing that I'd like to accomplish is introducing our software students to some of the basic concepts of version control. Personally when I started my job I didn't know what version control was, and needed to learn it really quick. Any exposure that students get to it will be useful if they end up pursuing software engineering.

[Astronouth7303]

Yes, SourceForge does use ViewCVS (which is also a SF project). For a web client, this is what I would use (if you have Python).

For a local client, I use TortoiseCVS.

If you're talking about server software, check Google.

[NoodleKnight]

Yeah, I'm talking about a server application. We do have multiple programmers working at once, not only at our robot headquarters but also at home, anywhere they want. One of the programmers suggested me to get a CVS server up, he has a server but he can't keep it online. Also, I'm hoping to use the CVS for more than just robotics, me and a few other friends have been working on programming projects.

[HFWang]

Originally Posted by Alan Anderson

Documentation and structure are always important, but as long as it's a single project under the control of one person (or two working closely together), formal change management is an added layer of complexity that only pays off in the very long term.

Just curious, what extra overhead do you incur from using CVS/SVN over copy/pasting?

[nathanielreindl]

Originally Posted by HFWang

Just curious, what extra overhead do you incur from using CVS/SVN over copy/pasting?

Most of the overhead goes into the metadata tagging along with each commit. This includes version, committer, date committed, any comments made by the committer, and whatever else may fit there.

On another tangent, though, the neat thing about revision tracking systems like Subversion and CVS is that they have niceties for folks working on different systems (e.g., Windows and UNIX). If you'll recall, Windows and UNIX have traditionally used different newline delimiters, and after a while, having to deal with converting and reconverting text formats becomes a bit of a pain. These facilities neutralize that in the commit and make the necessary changes when grabbing the updated sources from the repository.

[Alan Anderson]

Originally Posted by Dave Flowerday

Perhaps that's the difference in our approaches. We attempt to re-use software as much as possible from one year to the next, so we don't consider our software to have a very limited lifetime.

How much software were you able to reuse from 2003 to 2004?

Oh, hang on a minute. You WildStang folk use coprocessors, don't you? That makes a big difference in our worldviews. You probably do have lots of code you reused between Stack Attack and First Frenzy...just not the code running in the IFI system. When I talk of a "single project", I'm referring to the files that make up one program. You have multiple programs running in one robot, so that's already into the realm where I said I'd be happy to use a formal version control system.

[Alan Anderson]

Originally Posted by HFWang

Just curious, what extra overhead do you incur from using CVS/SVN over copy/pasting?

I was referring to complexity, not overhead. Copying the source code to a backup folder each day (or after each major change) is simple, needs no extra software to support it, and requires no special training in order to use. When the programming project. On the other hand, using a "real" version control system means that either specialized software must be installed on each computer to be used, or a network must be maintained between them and a server. The people working on the program also need to learn how to use the system effectively.

There's actually a whole lot of "overhead" in a daily (or more often) duplicate scheme. Most of the program doesn't change, so it's redundant to keep it multiple times. A good version control system will store changes as a "delta", saving significant space.