EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

We maintain a live copy of the scenery tools code via GIT.  But as of now it’s in a temporary coma – I made a CVS admin change to the original CVS repo to fix a screwed up checkin and the GIT bridge somehow got out of sync.  Janos is trying to figure out how to fix things now.

If we need to release new builds of scenery tools before we fix this, I’ll post snapshots of the source code. If you need live access (e.g. you take source updates via GIT) ping me, or perhaps ping Janos directly.  I’m hoping we’ll have this fixed in short order.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

7 comments on “Scenery Tools GIT Repo Down (Temporarily)”

  1. It is fixed now, more or less. Changes from the CVS tree will now be incorporated manually into the GIT repository by me. If someone has troubles with the new repository, please drop me a note.

  2. Why this mess with CVS anyway?
    Wouldn’t it be more comfortable to just host a git repo on the server, and let users check out either natively via git clone or, if they like working with paleolithic equipment, use git-svn or git-cvsserver on THEIR side? This would definitely save you a lot of trouble on the server side.

    1. CVS is not there because we think that users might want to use it. It’s there because all (actually a proposition, i don’t really know) developers of Laminar Research are using CVS for daily development. GIT is just here, because I didn’t want to use CVS when I did start working on the scenery tools. This is the reason why we have this unusual setup, and it will last until Ben himself decides to drop the CVS repository. Maybe I’ll have my quantum computer until then 😛

      2. Laminar’s repos are cvs? Yikes.

        The learning curve for a dvcs like git is exaggerated. Improved development tool functionality and efficiency (easy branching and merging, to start) gained from using a dvcs should more than make up for any hassle involved in converting an existing cvs/svn repo.

        From an operational perspective, having a dvcs repo with cryptographic hashes to ensure integrity of old commits is valuable. Ask sourceforge and kernel.org which have both been hacked recently.

Comments are closed.