SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

Yeah, sorry about that, my availability this week has been dreadful.

Reading back down the last few posts, it's clear there are a few issues with your current setup. This ties into a few things that are (slowly) happening behind the scenes with OHM in general.

The current plan runs thus:

1. Develop a RESTful API to serve as the core of the OrbitHangar repository site
2. Develop a new website frontend to leverage this core API
3. Implement an authentication "hook" to provide some form of single-sign on between the forum and the API core
4. Link the API to additional services such as GitLab, IRC notification, etc

Some of the items on this list have had some work put to them, but none of them are yet production-ready. In particular, we have a copy of GitLab running on my kit for testing purposes, within which the current code for the RESTful API is hosted (using git, of course). This will ultimately form an attached service as part of the final list item once the other pieces are in place, but naturally things only proceed as free time allows us to make progress on them.

It would be possible (and quite easy) to afford this project space within the aforementioned GitLab instance, but that would naturally mean the project migrating to use git instead of SVN. There is not currently an SVN server set up for the purposes of OHM as such, but I do run a subversion server for the D3D9 client (again, on my kit) which, equally, I can provide SSU space in if retaining SVN is desirable. This may over time become integrated with OHM itself as the GitLab instance, though this is a more convoluted process.

So, in short, you can have your cake and eat it just fine if you want, though the current state is much less mature than I'd like.

Thanks for the reply!

So, if I understand correctly, the options are:
1) go git and get in a "stable platform"
2) stay in SVN and (maybe) later have to migrate
Correct?

 

[Lucy]

Thanks for the reply!

So, if I understand correctly, the options are:
1) go git and get in a "stable platform"
2) stay in SVN and (maybe) later have to migrate
Correct?

Well, not as such. If your project wishes to stay SVN, I'm more than happy to accommodate that ad nauseum - I despise the idea that you should have to migrate to use something different "just because". GitLab naturally doesn't do SVN, but I'm open to looking into similar solutions if any exist (to provide a similar experience, web-interfaces and such, like GitLab provides git repos).

In the first instance, it's probably easier for you to remain in SVN since you're already in SVN. I'm not certain about retaining repository history with a migration this way (I can't recall why the history on the Orbiter repository was lost at the moment, I'm sure it'll become apparent later) but I have in the past migrated SVN to git and adequately represented the old SVN history in the new git history.

So, really, the choice is all yours. You could decide right now to switch to CVS and migrate to OHM, and we'd find a way to sort that out (but please don't, CVS is awful).

 

[DaveS]

Well, not as such. If your project wishes to stay SVN, I'm more than happy to accommodate that ad nauseum - I despise the idea that you should have to migrate to use something different "just because". GitLab naturally doesn't do SVN, but I'm open to looking into similar solutions if any exist (to provide a similar experience, web-interfaces and such, like GitLab provides git repos).

In the first instance, it's probably easier for you to remain in SVN since you're already in SVN. I'm not certain about retaining repository history with a migration this way (I can't recall why the history on the Orbiter repository was lost at the moment, I'm sure it'll become apparent later) but I have in the past migrated SVN to git and adequately represented the old SVN history in the new git history.

So, really, the choice is all yours. You could decide right now to switch to CVS and migrate to OHM, and we'd find a way to sort that out (but please don't, CVS is awful).

I certainly think that staying with SVN (and I do have some limited experience with CVS) is the most efficient solution. As far as keeping the repo history, I posted a link to a migration guide earlier but here it is again: https://www.petefreitag.com/item/665.cfm

 

[GLS]

Well, not as such. If your project wishes to stay SVN, I'm more than happy to accommodate that ad nauseum - I despise the idea that you should have to migrate to use something different "just because". GitLab naturally doesn't do SVN, but I'm open to looking into similar solutions if any exist (to provide a similar experience, web-interfaces and such, like GitLab provides git repos).

In the first instance, it's probably easier for you to remain in SVN since you're already in SVN. I'm not certain about retaining repository history with a migration this way (I can't recall why the history on the Orbiter repository was lost at the moment, I'm sure it'll become apparent later) but I have in the past migrated SVN to git and adequately represented the old SVN history in the new git history.

So, really, the choice is all yours. You could decide right now to switch to CVS and migrate to OHM, and we'd find a way to sort that out (but please don't, CVS is awful).

Once again, thanks for the SVN offer! I guess we'll take it!
Here's the (old) path svn://svn.code.sf.net/p/shuttleultra/code/
From what I'm reading about moving repositories, it should be "just" dumping the original repo and then loading in the new one, and the history should be there... but theory and practice don't always match... :uhh:

As for the tickets, we just have to come up with something here... a single thread, or individual threads (probably better).

Again, thanks a million!

 

[Face]

I'm not certain about retaining repository history with a migration this way (I can't recall why the history on the Orbiter repository was lost at the moment, I'm sure it'll become apparent later) but I have in the past migrated SVN to git and adequately represented the old SVN history in the new git history.

I think that if you can take an svnrdump file (apparently created by DaveS already) and clone the SVN repo with history onto your server infrastructure, so that it is hosted like Orbiter beta or D3D9Client, the team here would be happy for a while.

 

[kuddel]

SVN remote backup script

Hi there,
as promised here's the backup script to make remote backups a bit more efficient.

What it does is (generally speaking):

1. Generate a local copy of the repository (if not present yet)
2(a) Get the HEAD revision number of the remote repository
2(b) Get the HEAD revision number of the local repository
3. If the local repository's HEAD revision is less than the remote repository's HEAD revision,
dump the "missing" revisions from remote repository into the local copy.
If the local repository is "up to date", report and do nothing else.
4. ZIP the local repository's content.

Therefor it's much more efficient than make a complete dump every time.
It's a kind of incremental sync.

The local copy of the repository should be kept in order to let the incremental
backup work.
The local copy of the repository is a fully functional repository! It's a windows filesystem structure however that might not be compatible to be just copied onto any *NIX system due to file-attributes etc...

If however you delete that folder, the complete repository will be re-created,
thus needing to transfer the *full* repository content over the network.



Regarding file-sizes:
- Currently (as of SSU revision 2717) it creates
- a local repository size of 1.544.535.573 bytes;
- a "zipped" repository size of 836.199.968 bytes.

Regards,
Kuddel

P.S.: I had to add ".txt" file-extension to the batch file (ssu.bat), to be able to upload it here.

 

[DaveS]

I think that if you can take an svnrdump file (apparently created by DaveS already) and clone the SVN repo with history onto your server infrastructure, so that it is hosted like Orbiter beta or D3D9Client, the team here would be happy for a while.

Yes, I got a full dump (not just the trunk, but the entire repo, tags and branches as well).

 

[Face]

Regarding file-sizes:
- Currently (as of SSU revision 2717) it creates
- a local repository size of 1.544.535.573 bytes;
- a "zipped" repository size of 836.199.968 bytes.

I can confirm that size range. Besides the trunk, I've got the following (public) branches:

VC                   
OrbitersimBeta       
ius-1.0              
ShuttleCentaur       
mps                  
3.0-release          
LC39                 
SSUToolbox           
OI-1                 
NewOrbiter-FromTrunk (closed)
NewOrbiter           (closed)
Mesh-Rev1463         (closed)
EntryGuidance        (closed)
2.1-newmesh          (closed)
../2.1-newmesh       (closed)

and the following tags:

4.2                 
4.1                 
4.0                 
3.0                 
version-2.0         
Ultra 25Jan2008     
LastDeluxe          
Original MG_Atlantis

 

[Lucy]

Okay, that was bigger than I envisaged, but the migration is done. You should find that everything is the same if you take a peek at svn://svn.orbithangar.com/shuttleultra/

As for the tickets, we just have to come up with something here... a single thread, or individual threads (probably better).

So there are a number of issue tracking tools you could go with - Orbiter Forum has "projects", which offer a sort of issue tracking capability (we use these for Orbiter bugs, Site Support, and the OHM rebuild project). It's also possible to track issues in GitLab, though that makes less sense if you're not using GitLab for the repository itself. Alternatively even still, there are third-party tools like trac, Redmine, Bugzilla, and many many more. These things are all trivial to stand up on the same infrastructure (and it costs me nothing to do), so if there's something out there you'd like to use for that, let me know and I'd be happy to get it up and going for you.

 

[Face]

You should find that everything is the same if you take a peek at svn://svn.orbithangar.com/shuttleultra/

A plain checkout with SVN CLI on /trunk with that endpoint gives me revision 2165, which is rather old. It should be 2817.

 

[GLS]

Okay, that was bigger than I envisaged, but the migration is done. You should find that everything is the same if you take a peek at svn://svn.orbithangar.com/shuttleultra/



So there are a number of issue tracking tools you could go with - Orbiter Forum has "projects", which offer a sort of issue tracking capability (we use these for Orbiter bugs, Site Support, and the OHM rebuild project). It's also possible to track issues in GitLab, though that makes less sense if you're not using GitLab for the repository itself. Alternatively even still, there are third-party tools like trac, Redmine, Bugzilla, and many many more. These things are all trivial to stand up on the same infrastructure (and it costs me nothing to do), so if there's something out there you'd like to use for that, let me know and I'd be happy to get it up and going for you.

Thanks!!!

Two questions:
1) How do we get write access?
2) Protocol? svn? https?

---------- Post added at 11:06 AM ---------- Previous post was at 11:00 AM ----------

A plain checkout with SVN CLI on /trunk with that endpoint gives me revision 2165, which is rather old. It should be 2817.

I can confirm it's (still) on r2165... but it's super duper quick compared with SF.

 

[Lucy]

A plain checkout with SVN CLI on /trunk with that endpoint gives me revision 2165, which is rather old. It should be 2817.

Apologies, the import job appears to have ended prematurely. I've recreated the repository, which seems to have brought it up to 2817.

 

[Lucy]

Thanks!!!

Two questions:
1) How do we get write access?

To recreate this, I guess I need a list of everyone to re-add, and then I'll generate and issue new passwords for your chosen usernames.

2) Protocol? svn? https?

Just svn for now. I can add HTTPS if it's preferred.

 

[Face]

Apologies, the import job appears to have ended prematurely. I've recreated the repository, which seems to have brought it up to 2817.

No need to apology, thanks for doing the work! It looks good now. :thumbup:

 

[GLS]

To recreate this, I guess I need a list of everyone to re-add, and then I'll generate and issue new passwords for your chosen usernames.

Currently the ones in use are:
gls_ssu
daves-ssu
urwumpe

Just svn for now. I can add HTTPS if it's preferred.

There should be no problems with svn, thanks!

 

[Lucy]

Usernames added and passwords issued via PM, you've got mail!

 

[GLS]

Heads-up: I'm finishing the checkout, and then I'll commit a small change as a test.

---------- Post added at 12:21 PM ---------- Previous post was at 12:14 PM ----------

I'm getting this on commit: Authorization failed

 

[Lucy]

Heads-up: I'm finishing the checkout, and then I'll commit a small change as a test.

---------- Post added at 12:21 PM ---------- Previous post was at 12:14 PM ----------

I'm getting this on commit: Authorization failed

I've restarted the SVN serve daemon, it might have been because I hadn't yet loaded the new config. Can you try again?

 

[GLS]

I've restarted the SVN serve daemon, it might have been because I hadn't yet loaded the new config. Can you try again?

Sadly it isn't working.

 

[Lucy]

Sadly it isn't working.

I have reconfigured. One more time?