Vesta Releases First GPL Version

Eugenia writes: "Many are the developers who prefer Perforce in favor of CVS. There is a new player in the field now though. It is called Vesta and it is a replacement for both CVS and 'make'. It handles source revision control and automated construction. It is the result of over 10 years of research and development at the Compaq/Digital Research Center. Just last August Compaq gave the 'ok' to GPL Vesta and since then the 4-member team worked hard to finish up the port to x86 Linux (prior to that, Vesta only worked on Alpha and Tru64 systems). Now, the first Free version is available for download. For a summary of some of the features that make Vesta interesting, see this page."

Comments

CVS is King!

[His name cannot be s]

Actually, my point is, that until someone makes their version control system a drop-in replacement for CVS, CVS will still remain the king.

I like the fact that I can use several different clients for CVS.

On Windows :

WinCVS is a nice CVS system for windows.

CvsIn is a plug-in for MS Visual C++ written by Jerzy Kaczorowski.

TortoiseCVS is a plug-in for Windows Explorer written by Francis Irving.

cvsscc is an SCC interface for CVS.

Jalindi-Igloo is a SCC interface for cvs using the WinCvs shared libraries. It's written by Graham Robertson and it's free!

There's also the command line version.

On Linux, there is a ton more choices.

The simple fact of the matter is there is a million different ways I can access the same repository, no matter my platform.

Until someone comes out with the server that supports CVS's whacked out protocol on port 2401, I ain't ever gonna switch.

I've been running the same CVS repository for about 4 1/2 years on an old Pentium 90 in my basement. I've got hundreds of project sitting on it, and it works fine.

Yes, I'll acknowlege that CVS has it's down sides, but hey, at least it's universal. ;)

Re:CVS is King!

[Cuthalion]

If you're going to be using it through the CVS protocol, you might as well just use CVS - you're not exposing any new features or anything (such as filesystem integration, automatic dependency detection, atomic multi-file checkins, password encryption, whatever else that might prompt you to not use CVS's crappy protocol).

CVS works "good enough" for that most important step - from no version control to some. This is much more significant than the differences between bad version control and good version control. It's gratis, it's libre, so a lot of people use it.

DOS used to be universal too. Aren't you glad we've moved on?

On the other hand, I'm certainly not going to switch anything over to Vesta until it has been ported the OS I do my development under! Until then, I heartily recommend TortoiseCVS.

Re:CVS is King!

[His name cannot be s]

DOS used to be universal too. Aren't you glad we've moved on?

Um, not quite the same thing. And not quite 'universal'... As a matter of fact, there were more choices back then... ;)

I heartily recommend TortoiseCVS.

Oh! Me Too. As a matter of fact, that somewhat validates my point. I like Tortise. I also like that I can drop down to the command line anytime. Until a CVS-up-and-commer makes drop-in dlls, exes and shared libaries that can look like CVS (not from a protocol level, but an interface level) where Tortise won't know the difference, I have no good reason to switch. Basically the flexibility and massive availibility of CVS outweighs its shortcommings.

Re:A rash of options...

[sien]

CVS does have some problems. In particular, there should be a way of checking in all the files of a change at once, and having the check in built to see if it actually works properly. The complete check in should be an ACID transaction. There should also be nicer ways of browsing the repository. Comparisons between the systems are few and far between. I've never seen a good one. But that's like most tools because most of these questions wind up being quite specific to the task at hand. But really high quality technical comparisons are really hard. I've written poor ones myself and had to admit that what I'd looked at did not really capture the differences. One's I've had to deal with recently are Direct 3D vs OpenGL, Visual C++ .NET vs Borland. And even thinking about language comparisons makes my head hurt. There are reports in other fields ( think Jane's ) that are really high quality and high cost.
But anyway - if you do the comparison it'd be great to see it up on a web page.

Re:A rash of options...

[j.e.hahn]

In opening, what is wrong with CVS? If it's such a big piece of shit, where are CVS' authors to address the problem?

Well, for one, some of CVS's "authors" (karl fogel is a big name in CVS circles) are the very same people that started subversion to solve CVS's problems. There are a number.

The biggest 3 problems, in my experience, with CVS are binary files, [lack of] atomic commits, and branching.

Binary files, for better or for worse, get checked in all the time. Having to tell CVS that it's a binary file (and having it hose the binary if you forget) is a PITA. It's much better to assume everything that isn't immediately recognizable as text is a binary. (this is what perforce and subversion try to do, and they both do a good job from what I've seen.)

Anyone who's ever done CVS style branches and then tried doing it the way perforce and subversion do it will tell you that the latter is far preferable. If you aren't familiar, perforce and subversion both work by doing brances as lazy copies (with history pointers) in the filesystem namespace. This make life easier. It also simplifies file revision #'s.

Atomic commits aren't a big deal when there's only one developer (or one developer per given piece of code.) But as soon as several people start developing it can get messy. With atomic commits, since an entire set of changes succeeds or fails, you eliminate the hassle of corrupted code for the most part.

I, for one, really like perforce and can't wait for subversion to be released. It looks to have the best of both worlds.

Re:How to get the source code

[janic]

Simple solution.

Use their binary, download their code, export it, and put it into CVS if you really want.

I have to agree with them though, there is little point to building a tarball of the source. There are, after all, tons of other projects which use soley(sp?) CVS to distribute their code.

At least using Vesta to download it's own source, you can be pretty well guaranteed that you will be getting the latest and greatest version, and not some broken release that someone hasn't bothered to take off their website.

John

Not usable for internet collaboration

[aminorex]

Vesta requires NFS export from the server to all
clients. This is not a feasible mode of operation
for a typical distributed development team, with
some users on 53k dialups with dynamic IPs. It
means you have to put the source server outside
the firewall, for example, which is just a non-
starter as far as I am concerned.

CVS is still king.

Re:Not usable for internet collaboration

[[Xorian]]

That's not the way you would use it for collaboration. The NFS interface is not intended for wide-area access, only for clients within an installation (which can be as small as one system).

The right way to use it is for each contributor to run their own Vesta repository and use Vesta's replicator to keep up to date with other repositories (such as a central master). Vesta's checkout tool automatically contacts the master repository, even if it's remote, and its checkin tool replicates the checked-in version back to the master repository.

We already have several users who work this way, one even running their Vesta repository at the other end of a 56k dialup line.

(BTW, I'm the current maintainer, the one who did much of the work of getting it ported to Linux and released.)

Re:Not usable for internet collaboration

[aminorex]

Thanks for commenting. Clearly my evaluation
overlooked important aspects of Vesta's operation.
What I took to be a deficiency, in light of your
comment, is actually a strength: The lack of local
history storage in remote CVS clients has often been
a problem for me in disconnected operation.

I'm definitely going to delve further into Vesta.
I hope moderators will take note of the parent, and
mod it up, so that other evaluators will take note
of Xorian's point.

Re:How to get the source code

[[Xorian]]

I kinda figured it wouldn't take long for someone to bring up the spectre of Vesta as a Trojan and reference that classic Thompson piece.

You could certainly do what you describe. Feel free. Extract the sources from the Vesta repository, re-write the entire build description in make, and re-build. (We actually have a web interface to the repository that we're hoping to put up soon so that people can examine and even download the source without having to install Vesta.)

In fact, I challenge anyone so inclined to try and uncover any malicious code in the binaries we've released. It would be nice if someone who was not only paranoid enough but also motivated enough to follow through with that came out of the woodwork. Then perhaps we could have a better response for the next person to cast such aspersions.

We're not distributing tarballs of source for exactly the reason stated in the FAQ: you wouldn't be able to build it without writing new build instructions for make or some other builder. I don't have the time or inclination to write Makefiles to build Vesta. If somebody else wants to, that's fine, that's why its free software.

Re:How to get the source code

[aminorex]

Use their binary? You must be joking, right?
Just run some random binary code I found on the
Internet? You're a terrorist, aren't you?