Vesta Releases First GPL Version 24
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."
Vesta (Score:1)
A rash of options... (Score:1)
With arch [regexps.com], subversion [tigris.org], Bitkeeper [bitkeeper.com], Perforce [perforce.com], and Starteam [starbase.com] there is a large group of choices for someone setting up a new project. Having the choice is a good thing, but there is a lack of good information on the topic.
I'm looking to get a RCS setup soon for an open source project, and this article reminded me that maybe CVS isn't a given. To decide, I can go read the docs for each, set each one of them up, and find the one that best suits me. Man, that's gonna suck.
Someone needs to sit down with each of these (and any others of significance) and really do a comparison. Investing the time to get your brain wrapped around a new RCS is very expensive.
Re:A rash of options... (Score:3, Insightful)
But anyway - if you do the comparison it'd be great to see it up on a web page.
Re:A rash of options... (Score:3, Insightful)
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:A rash of options... (Score:1)
Excellent question. As I was one of the people on the EV8 team who
drove the decision to adopt Vesta, I can offer my perspective.
I am and was a CVS user. We used CVS for the EV8 performance model.
We used RCS/Make for the EV6 models. We used CMS/MMS (a rev
control/build toolset for VMS) for previous projects. They all had a
set of problems that I decided were not acceptable for the EV8 RTL
(hardware description language and verification) effort.
1. All three provided nearly adequate revision control, but the lack
of an encapsulated build environment caused problems in two (fairly
common) scenarios:
a) Engineer transfers from box X to box Y (from one section of the chip
project to another). Because of the peculiarities of box Y, they use a
slightly different set of environment variables to talk to the various compilers/linkers/verification scripts.
So, he logs in using his old environment, builds a model for box Y that doesn't work quite right.
Yes we can fix that with discipline, but mechanical encapsulation works much better. There are many solutions to the problem that still use CVS. We chose a tool approach.
2) Bob is working on a bug reported against model version 3-15-99. Alice is working on a different bug for the same model. Alice discovers her bug is related to a problem with the RTL compiler. So, she gets the maintainer to ship and install the upgrade.
Bob recompiles with the new compiler and his bug moves (or disappears-- why? did the compiler "fix" it, or did the compiler just hide it. --- we've seen both instances.)
Yes, you can construct multiple "release areas" and select them with environment variables -- that's what we did on some earlier projects. This solution was viewed as somewhat unsatisfactory. (it adds ONE more environment variable/magic switch to keep track of.)
2. Our experience with CVS in the performance model environment indicated that it was difficult to use CVS to manage configurations (as opposed to revisions.) That is, I want to build model A with version 6.5 of unit X, version 6.3 of unit Y -- but someone else wants to build model B with version 6.5 of X and no unit Y, but version 0 of unit Z. We wanted a simple, common, and interchangeable way of representing these builds. Make works, but as experienced users of Make will know, often becomes cryptic when one starts to use it for configuration management.
3. Additionally, CVS version tagging is not as rich as Vesta's build package system. We made significant use of the latter.
4. Finally, to some this will seem a nit and perhaps it is. CVS and RCS rely to some degree on Time-of-Day clocks for revision id. We operated over a huge geographical area in multiple time zones where the systems aren't always synced to a common clock. If I were king, this wouldn't be a problem. Alas, big IT organizations will conspire against us.
As for comparison to the other systems, I'm pretty sure the comparison text was written before these came along. (I haven't seen it, xorian -- was this material taken from the survey that WA wrote back in '98?)
By the way, folks who've used both the CVS/Make approach and the Vesta approach to RTL development are, in general (perhaps universally), of the opinion that Vesta was the correct choice.
What I want to know... (Score:1)
I find it interesting that in their Assessment of Various SCM Systems [vestasys.org] there is no mention of BitKeeper [bitkeeper.com], Arch [regexps.com], or Subversion [linuxjournal.com], all of which have been brought up here in the past [slashdot.org].
Does anyone know how they compare? It seems to me as though this space is becoming increasingly crowded. Choice is a good thing, I just fear that it might be at the cost of being able to easily communicate code between developers.
CVS is King! (Score:3, Informative)
I like the fact that I can use several different clients for CVS.
On Windows :
WinCVS [wincvs.org] is a nice CVS system for windows.
CvsIn [geocities.com] is a plug-in for MS Visual C++ [microsoft.com] written by Jerzy Kaczorowski [mailto].
TortoiseCVS [slashdot.org] is a plug-in for Windows Explorer written by Francis Irving [mailto].
cvsscc [home.net] is an SCC interface for CVS.
Jalindi-Igloo [jalindi.com] 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! (Score:2, Interesting)
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! (Score:2)
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.
How to get the source code (Score:1)
They're not going to get much traction in the linux community that way. If you can only get and build the source by using a built binary of their tool you installed from somewhere else, then how can it be trusted to be showing you the actual source, and not some decoy source hiding bugs or malware?
Re:How to get the source code (Score:2, Informative)
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
Re:How to get the source code (Score:1)
http://www.acm.org/classics/sep95/ [acm.org]
Re:How to get the source code (Score:1)
What I'm getting at is, (and this also applies to the reply previous to yours,) that once you export the source from the tool, it is no longer under it's control.
Once you have source that is under your (and only your) control, you can audit it as you see fit, and complile it for whatever platform you want. (LGPL, remember?) Nuke the Obfuscated bits and replace them with your own, if you are so inclined, and once it reaches your level of trustworthyness, release it back to the community via public CVS.
Now let's look at the marketing aspect of this for a sec:
Oh, wait a second! you mean that your Uber Powerful Vesta (UPVesta) source control system is not even powerful enough to host it's own source?
Holy smoke! They have to go back to tarballs to distribute their stuff for Pete's sake! That's not leet enough for me.
(/self snips rant to prevent being branded as a troll)
Etc.
My point is, that Vesta is not a compiler, and, unless they have infiltrated the GCC team, it would seem that once you compile any source that has been exported (read wrested from the evil clutches of the source control system, not that Vesta is inherently evil) from Vesta, WYSIWYG!
John
Re:How to get the source code (Score:3, Informative)
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 (Score:1)
The funny thing about most of the people incanting the "Trusting Trust" article is that I bet that half of them have not really read it.
I'll be trying Vesta out sometime this week. I'm looking forward to see how CVS, Subversion and Vesta stack up to one another.
Cheers!
John
Re:How to get the source code (Score:2)
Just run some random binary code I found on the
Internet? You're a terrorist, aren't you?
Re:How to get the source code (Score:1)
Not usable for internet collaboration (Score:2)
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 (Score:4, Informative)
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 [vestasys.org] to keep up to date with other repositories (such as a central master). Vesta's checkout tool [vestasys.org] automatically contacts the master repository, even if it's remote, and its checkin tool [vestasys.org] 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 (Score:2)
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.
Used by Compaq's Alpha group, now Intel (Score:1)
As noted in the Inquirer's article on Vesta [theinquirer.net], it was used by the Alpha microprocessor group on the EV8 (aka Araña) project. Most of the people who used Vesta on that project are now a part of Intel, working on a future IA-64 processor. They are continuing to use Vesta under Intel.
(For the sake of disclosure, I'm one of the people who worked on that project and now work for Intel.)