Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Vesta: an excellent source-code mgmt system  (Read 1143 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2004-03-12 22:49:55 »

http://vestasys.org

Now that it's finally java-compatible (c.f. my recent posts in the general thread about getting the JDK into a virtual FS Smiley), I'm going to suggest Vesta to you all. And especially to those not using an SCM at the moment - vesta takes only a couple of minutes to setup, and without the pains of CVS etc leaves many people with no good reason not to use an SCM Smiley.

We think it's good enough that we've spent considerable time getting Vesta to work with java (more on why that's important below), and moving all our source code from existing systems onto Vesta; I'm only suggesting it here because I genuinely believe it is *that* good (and some here will probably remember how high my standards are for SCM's Wink). Anyone who tries it and wants the java integration stuff, just mail me and you can have it (it's very small, it just needed some serious debugging to get it to work Smiley).

General reasons why you might want to move to Vesta:

  • It's free (LGPL, on sourceforge)
  • It's very easy to install and configure (compared to e.g. CVS). Just a couple of RPM's and answering a couple of basic questions.
  • It was designed and written in-house to manage the DEC Alpha microprocessor development teams. This is not a toy project, it's a serious SCM that's been in commercial use for years (and is still in production use at Compaq and Intel on three continents).
  • It has the features and the reliability that the big chip companies demand. Including lots of good documentation (although the FAQ is rubbish)


It's a bit different from most non-expensive SCM's, e.g.:

  • It automatically mounts the repository into your filesystem - you can just "cd" into the repository directly, and read and execute your classes and JAR's without first checking them out (and you have all your normal shell commands and aliases)
  • Replication of repositories was built-in to the original design; DEC Alpha had a dev team split between the west and east coasts working on the same code. Replication is very easy and designed to replicate hundreds of megabytes daily.
  • Distributed builds were also built-in: setting up a "build farm" is easy, and gives you parallelized builds
  • Compiling is done within Vesta. Yep, that's right - it does your compiling for you, as part of the build process. At first this might sound strange, but it means that every build is 100% repeatable.
  • Every part of every build goes in a cache shared by every user - this is automatic distributed incremental builds. Builds tend to be very very fast (even more so when you have more developers).


The last two points are the most important. In C, the repeatable builds is a huge advantage (because there are so many libraries that introduce new bugs in successive versions). In Java this is less true, unless you use a lot of external libs - or do a lot of native compiling (note: no-one has made JET integration yet, although this could be a huge boon to JET developers if they did).

There is a big disadvantage, though: There currently isn't a server binary for Windows. This means you need a linux or unix machine to host the repository. Client access requires NFS which is usually built in to linux etc, and Microsoft made NFS a free upgrade for windows earlier this year. Some people also run samba to make the repository appear in windows networking (just as for mounting it in the FS: it means you can read and run classfiles, but you can't use this method to checkout/checkin without some extra jiggery-pokery).

FYI, before moving to vesta we had a hodge-podge of SCM's - CVS (buggy, prone to corrupting your source-code, slow, and difficult to setup new systems), RCS (less buggy, missing vital features such as checking-in whole packages at once: RCS can only check-in individual files, which gets VERY painful on large projects), and some half-breeds, part RCS, part CVS, part Windows-Explorer integration. I make no secret of my hatred of CVS (having nearly missed deadlines because of source-code corruption), and I know that a lot of people love it (fair enough, if it works for you). I don't want to start a flame-war, I'm only saying this as a disclaimer so that you're aware of my bias Smiley.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-03-13 02:11:57 »

Quote

In C, the repeatable builds is a huge advantage (because there are so many libraries that introduce new bugs in successive versions). In Java this is less true, unless you use a lot of external libs - or do a lot of native compiling


I'm tired. That shouldn't just say "external libs" it should say "...or use java packages or classes that someone else is working on".

e.g. If you and four colleagues are each working on one of 5 packages: a.jar, b.jar, c.jar, d.jar, e.jar, and you have a problem with b.jar (your package) which has developed a strange bug you think might be the fault of the developer of c.jar (which several classes in b.jar import), then you don't need to confer with the other person about which version of c.jar you were using (and don't need to worry about making a mistake!) - a given version of the sources for b.jar are tied immutably to a precise version of c.jar.

Just the action of changing the version of c.jar that b.jar uses automatically changes the version of b.jar - you *cannot* compile against any-old version of any dependent package, lib, classfile, or etc - the SCM automatically ensures you only ever compile against precise versions that you can then retrieve at a later date.

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (50 views)
2014-04-15 18:08:23

BurntPizza (46 views)
2014-04-15 03:46:01

UprightPath (62 views)
2014-04-14 17:39:50

UprightPath (44 views)
2014-04-14 17:35:47

Porlus (61 views)
2014-04-14 15:48:38

tom_mai78101 (85 views)
2014-04-10 04:04:31

BurntPizza (143 views)
2014-04-08 23:06:04

tom_mai78101 (242 views)
2014-04-05 13:34:39

trollwarrior1 (201 views)
2014-04-04 12:06:45

CJLetsGame (208 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!