Orbiter beta SVN repository

[martins]

Hi everybody,

From today, Orbiter beta snapshots will be provided via a Subversion repository on orbithangar.com. Vash has kindly set up the repository at https://orbithangar.com/svn/orbiter/trunk.

The SVN repository has a few significant advantages over the previous 7-zip diff file method:

• It allows me to push new beta updates more frequently, whenever a new feature or bug fix has been implemented, rather than accumulating a lot of stuff before uploading a new beta
• It's easy to go back to a previous beta version
• It is easier to keep the change log in sync with the updated versions

In order to check out a beta snapshot you will need an SVN client such as TortoiseSVN.

Note that from now on, beta versions will no longer be identified by the 6-digit time stamp, but by the SVN revision number. Please keep that in mind in particular when filing bug reports.

The head revision currently submitted corresponds to the last "traditional" beta 121202. I have also created a tag for the Orbiter 100830 Release version at https://orbithangar.com/svn/orbiter/tags/orbiter100830/

Please let me know if there are any problems with the new setup.

Happy beta-testing!

 

[orb]

Please let me know if there are any problems with the new setup.

The only problem I noticed so far with that setup is that I write "svn up" every time I enter the Orbiter beta directory. :lol:

 

[kuddel]

Hi Martin,

is it on purpose that the two "CurrentState" HTML files were missing in rev. 10?

• Html\Scenarios\CurrentState.htm
• Html\Scenarios\CurrentState_img.htm

Maybe because the "BMP/JPG/PNG" changes have not been good enough?
Not a big issue per se, but the "could not display website" cought my eye (see attachment)

Nevertheless, have I already noted that I really love the SVN-approach? If not: I do! :thumbup:

Kuddel

 

[kuddel]

Hi again,
another PRO for the SVN-Repository is: I can provide patches that might alleviate your work[1]

I took the liberty to apply the same style as in all other Orbiter chm files for H1 headings.
Please feel free to ignore my input of course :thumbup:

/Kuddel

[1] Although ".diff" or ".patch" files should be added to the allowed attachment types

 

[orb]

[1] Although ".diff" or ".patch" files should be added to the allowed attachment types

They are allowed for projects, where usually bugs are reported. Projects also highlight changes in preview of a diff/patch file.

 

[kuddel]

They are allowed for projects, where usually bugs are reported. Projects also highlight changes in preview of a diff/patch file.

Thanks orb, for the info!

 

[martins]

I took the liberty to apply the same style as in all other Orbiter chm files for H1 headings.

Yes, I was considering it, but to be honest, I am getting a bit tired of the "green bar" headline style. It looks a bit heavy. I am rather thinking about modifying the default headline styles for all other orbiter documents, but I haven't decided yet on a new style.

 

[martins]

is it on purpose that the two "CurrentState" HTML files were missing in rev. 10?

Sorry about this. They were left out by accident, together with a whole bunch of other files. Should be fixed now.

I just realised that VisualStudio seems to modify all binaries on rebuild, even if they should not have changed. Does VS build a time stamp or similar into the executables? Is there a way to switch this off?

I hope SVN is efficient in encoding small changes in binary files, but even then it's a bit annoying that they are all flagged as modified.

 

[kuddel]

Sorry about this. They were left out by accident, together with a whole bunch of other files. Should be fixed now.

Thanks! Will update immediately

I just realised that VisualStudio seems to modify all binaries on rebuild, even if they should not have changed. Does VS build a time stamp or similar into the executables?

Yes, it does!

Is there a way to switch this off?

I don't hink there is such a switch. But if anyone has more information, I would be happy to know about!

I hope SVN is efficient in encoding small changes in binary files, but even then it's a bit annoying that they are all flagged as modified.

The diffs are quite effective, so no worries about that.

On the other hand you can still 'revert' all files that you are sure about they have no changes (apart from time-stamp), before you commit.
That of course implies the risk that you accidently forget to commit some changes...

/Kuddel

---------- Post added at 23:55 ---------- Previous post was at 23:47 ----------

As a side-note:
Here's a simple example for "plain-text to html" I used to have somewhere around:

#include "stdafx.h"
#include <fstream>
#include <iostream>
#include <string>

const char *filename_inp = "c:\\tmp\\input.b";

using namespace std;


string str_replace (string& in, string rep, string wit)
{
    size_t pos = 0;
    while ( pos < in.length() )
    {
        pos = in.find(rep, pos);
        if ( pos == -1 ) {
            break;
        }
        in.erase(pos, rep.length());
        in.insert(pos, wit);
        pos += wit.length();
    }
    return in;
}


// check wheter the line simply consists of '---' (2 or more!)
bool is_ascii_line(string& line) {
    return (line.length()>2 && line.find_first_not_of('-') == -1);
}


int _tmain(int argc, _TCHAR* argv[])
{
    ifstream inp(filename_inp);

    if ( !inp.bad() )
    {
        ofstream out(str_replace( string(filename_inp), "input", "output")+".html");
        string line;
        while ( !inp.eof() )
        {
            getline(inp, line);
            /*
            if ( is_ascii_line(line) ) {
                out << "<hr />\n";
                continue;
            }
            */
            str_replace(line, "&" , "&" ); // < must be first!
            str_replace(line, "\"", """);
            str_replace(line, "<" , "<"  );
            str_replace(line, ">" , ">"  );

            out << line << "<br/>";//\n";
            cout << ".";
        }
        out.close();
    }
    inp.close();

    return 0;
}

maybe it can be used for displaying plain text descriptions well formatted in the HTML-Viewer.

/Kuddel

P.S.: rev. 11 now has the missing files :thumbup:

---------- Post added 04-12-12 at 00:24 ---------- Previous post was 03-12-12 at 23:55 ----------

A (disappointing) info about comparing two successive builds: http://support.microsoft.com/kb/164151/en-us

There is no guarantee that Visual C++ will generate the same binary image when building the same source files on successive builds. However, you are guaranteed that the EXE (or DLL) will behave in precisely the same manner under execution, all other things being equal. Compile and link options and link order play a role in whether two binary images will compare equally.

 

[orb]

maybe it can be used for displaying plain text descriptions well formatted in the HTML-Viewer.

But first it needs to be detected that the text is a plain text and not HTML, either by parsing the whole description (or by simply counting the number of <'s and >'s if it's equal, to tell it's on 90% HTML ), or by requiring a <body> or some other (<div>, <span>) tag around the description if it's written in HTML, which would be checked before converting it between text/plain and text/html.

A (dissapointing) info about comparing two successive builds: http://support.microsoft.com/kb/164151/en-us

More in the topic: http://stackoverflow.com/questions/1363217/binary-reproducibility-in-visual-c

 

[kuddel]

But first it needs to be detected that the text is a plain text and not HTML, either by parsing the whole description (or by simply counting the number of <'s and >'s if it's equal, to tell it's on 90% HTML ), or by requiring a <body> or some other (<div>, <span>) tag around the description if it's written in HTML, which would be checked before converting it between text/plain and text/html.

Yeah, that's too much guessing! But what about a new section à la:
BEGIN_HYPERTEXT_DESC
END_HYPERTEXT_DESC
That - if present - is taken as HTML (without any conversion).
If only the 'old' BEGIN_DEC END_DECS block is present, it will be taken and always be converted.

Just my 2cts... Good night,
/Kuddel

BTW: Orbiter (even older versions) ignore any BEGIN_HYPERTEXT_DESC - END_HYPERTEXT_DESC block.

 

[Ripley]

So, I just installed TortoiseSVN yesterday, and I'm totally new to this way of managing software updates/downloads/whatever.

If I understood correctly, in order to get the latest Orbiter Beta, I only need to:

- right click and choose "SVN Checkout...";
- fill the first two fields with the beta repo address (URL of repository) and the folder where my beta will be placed in (Checkout directory), without blanks in its name;
- Click on "Show log";
- Select the latest revision that'll appear in the window;
- Confirm with OK.

Is that all?

 

[orb]

- Click on "Show log";
- Select the latest revision that'll appear in the window;

You don't need to "Show log" and select the latest revision if all you want is to get the last one. There should be HEAD revision radio button, like on the image below, which will get you the latest revision from the repository:

 

[Ripley]

Roger, "HEAD" is the latest version anyway.
Couldn't get simpler than that!

 

[kamaz]

Roger, "HEAD" is the latest version anyway.
Couldn't get simpler than that!

Actually, it gets simpler.

Once you checkout HEAD, right-click the checkout directory and select "SVN Update". That will automatically check if the repo is updated and sync changes to your directory.

In other words, you only need to do the checkout once, then you just use "SVN Update" to keep your copy updated.

 

[Urwumpe]

Actually, it gets simpler.

Once you checkout HEAD, right-click the checkout directory and select "SVN Update". That will automatically check if the repo is updated and sync changes to your directory.

In other words, you only need to do the checkout once, then you just use "SVN Update" to keep your copy updated.

Of course, this gets a bit confusing, if your Orbiter root folder is also used by another subversion project. But nothing that the (n+1)th orbiter folder on your HDD can't solve.

 

[Face]

Of course, this gets a bit confusing, if your Orbiter root folder is also used by another subversion project. But nothing that the (n+1)th orbiter folder on your HDD can't solve.

SVN also has an "export" command that writes out just the files of the working copy to a specific directory. This way you won't get the .svn meta data or collide with an add-on repo. Unfortunately it will not handle file removals, though.

My way of handling this issue is by means of merging the add-on repo with the framework repo in order to get a test repository. But of course I do not use Subversion for this.

regards,
Face

 

[Urwumpe]

SVN also has an "export" command that writes out just the files of the working copy to a specific directory. This way you won't get the .svn meta data or collide with an add-on repo. Unfortunately it will not handle file removals, though.

Yes. I meant the "update" command in that context. It is not possible to simply update the Orbiter beta installation in which you pre-test your add-on, if you also use Subversion there for the add-on.

Nothing prevents you from using Mercurial/GIT/etc. for your add-on and Subversion for Orbiter. :lol:

(But using an install target/task for your build process is likely better in the long term)

 

[Ripley]

I was trying an update.
Is this a problem on my side, or are you getting the same error?

 

[Face]

I was trying an update.
Is this a problem on my side, or are you getting the same error?

Confirmed. I get the same error.