Meadville Space Center
Welcome, Guest. Please login or register.
November 24, 2020, 01:09:42 AM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2267 Members
Latest Member: Apollo Next
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP News & Discussion
| | |-+  Support & Bugs (Moderators: movieman, Tschachim, Swatch, lassombra)
| | | |-+  CVS Server Problem???
« previous next »
Pages: [1] Print
Author Topic: CVS Server Problem???  (Read 2206 times)
barry
Full Member
***
Posts: 49


View Profile
« on: January 18, 2008, 09:51:30 AM »

I have had a problem trying to do CVS updates for the last day or two.  The CVS client connects, but eventually times out with no traffic.
The CVS Browser seems to work on the SF Website. If I had to guess, it looks like the "anonymous" password was changed - or could this just be congestion from the latest Beta Release?
« Last Edit: January 18, 2008, 10:04:31 AM by barry » Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #1 on: January 18, 2008, 10:05:25 AM »

There shouldn't be a password.  If you could post the contents of the CVS window, we might be able to help you.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
barry
Full Member
***
Posts: 49


View Profile
« Reply #2 on: January 18, 2008, 10:10:15 AM »

**** I use the command line cvs (and cygwin)

[barry@jordan apollo2]$ cvs login
Logging in to :pserver:anonymous@nassp.cvs.sourceforge.net:2401/cvsroot/nassp
CVS password:
cvs [login aborted]: reading from server: Connection reset by peer

*** I also tried a checkout with an implicit login

[barry@jordan apollo2]$ cvs -z3 co projectApollo
cvs [checkout aborted]: reading from server: Connection reset by peer

****  This occurs after a long pause. Its not a DNS, or a firewall issue - see below

[barry@jordan apollo2]$ ping nassp.cvs.sf.net
PING nassp.cvs.sourceforge.net (66.35.250.96) 56(84) bytes of data.
64 bytes from 16.cvs.sourceforge.net (66.35.250.96): icmp_seq=0 ttl=47 time=83.1 ms
64 bytes from 16.cvs.sourceforge.net (66.35.250.96): icmp_seq=1 ttl=47 time=86.3 ms
64 bytes from 16.cvs.sourceforge.net (66.35.250.96): icmp_seq=2 ttl=47 time=84.2 ms

--- nassp.cvs.sourceforge.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 83.103/84.556/86.328/1.356 ms, pipe 2

*** I can connect to the cvs port manually

[barry@jordan apollo2]$ telnet nassp.cvs.sf.net 2401
Trying 66.35.250.96...
Connected to nassp.cvs.sf.net.
Escape character is '^]'.
^]
telnet> quit
Connection closed.


Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #3 on: January 18, 2008, 10:30:51 AM »

The SourceForge servers aren't very reliable unfortunately, so I suspect a problem on their side and suggest to try again later, sorry.

Cheers
Tschachim
Logged

barry
Full Member
***
Posts: 49


View Profile
« Reply #4 on: January 18, 2008, 10:33:36 AM »

Will do.

If this persists for more than a couple of days (it has already been more than 36 hours) - might I suggest uploading periodic CVS snapshot tarballs?
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #5 on: January 18, 2008, 11:40:39 AM »

We've got a snapshot zip in the latest release pack.  Check out this page for a link: http://nassp.sourceforge.net/wiki/Installation
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
barry
Full Member
***
Posts: 49


View Profile
« Reply #6 on: January 18, 2008, 05:36:30 PM »

Just tried it - it works now.....

Thanks to whoever fixed it....
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #7 on: January 18, 2008, 05:43:38 PM »

We don't actually have any control over the CVS, that is 100% Sourceforge.net's deal.  We use their free service, and sometimes it's worth every penny we pay for it, and sometimes it's actually a good service.

I'm actually looking into putting a CVS server on my server, and maybe we can set up a mirror system so that if the sourceforge CVS is down, mine will be up (or maybe use the Sourceforge as a mirror since my site can handle the little traffic that this site puts out).
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #8 on: January 18, 2008, 05:50:00 PM »

I have a CVS server on my PC, but I don't think it's accessible outside; I found that useful when I was working on a dialup connection, as it was faster to copy over the CVS repository changes to my PC and then do a CVS update from there than to do a CVS update from sourceforge!
Logged
barry
Full Member
***
Posts: 49


View Profile
« Reply #9 on: January 18, 2008, 05:55:09 PM »

If its a read-only copy, it might be easier just leave daily tarballs on a public ftp site.

If you need backup servers for developers - it may be easier to have a distributed code control system like "git" - and each of the developers can pull from each other. You can leave pointers on the website to the various gits.  Check out http://git.kernel.org/ to see how the linux developers do it...
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #10 on: January 18, 2008, 11:04:31 PM »

Somehow I don't think anyone on this site is gonna much like that idea, especially since some of our developers have dialup, which is not good at all for a distributed source system.

In the end, the CVS on sourceforge serves our purposes, it is just a little unreliable.

I don't think our code changes that much that a daily snapshot is necessary, as we do a full build and snapshot about once a month as can be found on the sourceforge download page.

Of course, for some reason, the developer side of the CVS seems a little more reliable, and it might be a bandwidth issue, as the developer side likely doesn't get the hammering that the anonymous side does.

All in all, I think we provide sufficient access to our latest stuff, and two to three days without an update is not anything at all unless you really need that update for some development work.  I mean, we don't even have noticeable updates every two to three days.

That said, if you really think we should have daily snapshot tarballs, are you willing to make them?  We could certainly use more developers, and those of us who are working regularly on the project just don't have the spare time to put into making a daily snapshot and putting it on the download site.

Last, you seem to be a linux fan, so I can understand some of your mentality on this as most linux distro's update every one or two days and have major code updates added to the source trees every couple hours.  Our project just isn't that big either in code complexity, or in developer count to warrant such activity.  The anonymous CVS combined with the periodic snapshots created when we build beta module packs serves our needs more than sufficiently.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
barry
Full Member
***
Posts: 49


View Profile
« Reply #11 on: January 18, 2008, 11:22:46 PM »

Not a problem - if there isn't another server available that could run an automated tarball  builder every few days- then it probably isn't worth it.

It is just nice - when some new features are just landing (in this case the Checklist MFD) - to get the code within a few days of it being checked in.

Linux does take advantage of having lots of non-developers (like me) downloading, building, and running their intermediately versioned kernels as a means of QAing, and having more eyeballs spotting bugs before releasing to a larger non-technical audience.

For NASSP, I tend to CVS checkout, about once a week (more often if a feature I care about it being cooked), and do a full rebuild. I have found, and reported a few bugs that I have found during these cycles.

If I had more time - then I would certainly be contributing code - as it is, whatever spare time I have with this project is spent with learning about Apollo Operations, or reading the AGC code, or learning about orbital math.

If I am in a small minority - then you are certainly correct about it not being worth the effort to create the tarballs.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #12 on: January 19, 2008, 06:18:17 PM »

If you found someone who had the time to create daily snapshots and upload them, I'm sure that they would be seen as useful, at least at times when the server goes down.

It seems most of our serious beta testers these days do their own builds, and have found it tough to deal with the anonymous cvs being down.

It is just a matter of time, and none of us have the time to make daily snapshots, and any time we do have, I think, could be much better served cooking up code.

Having people on the team that are able to do some of this more support oriented side of it would be nice, and if you think you are one of those people, get in touch with Tschachim as we'd all love to have whatever help you or anyone else can provide to making this absolutely the best rendition of the Apollo projects that it can be.

I know for a fact that the linux distro I used to use (I won't name it as I know how possessive people can be about their fave distro) had a few people on the team who had no code experience whatsoever.  Their job was to document everything and to pack up the daily snapshots.  We just don't have anyone who has that kind of time and isn't devoting it to specific projects.

For example, once I actually finish the ChecklistController, I'm going to be spending a lot of time converting all our .doc checklists to the new automateable .xls format.  The quicker I get that done, the quicker we can actually do a release with the checklist MFD in it.

It all comes back to time, so I say again, if you do have the time, we'd love to have you on, even if all your able to contribute is on the support side (daily snapshots etc).
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
barry
Full Member
***
Posts: 49


View Profile
« Reply #13 on: January 19, 2008, 06:53:20 PM »

I could try...

The simplest thing would be an automated script to do a CVS pull, create the tarball, and then post it to the source forge file server (and any designated backup servers).

I have a server available to do this - but not to act as a public server. I may be able to host a password protected ftp or sftp site with a known list of users.

1) Is there sufficient space for some number of copies of the daily (or whatever) tarballs on SF.net?
2) Is there another public ftp server that could be used?
3) Does the whole tree need to be saved?

I would like to contribute code, but my day job restricts how much time I could devote

I have been a professional programmer for a long time (on most  modern technologies like C,C++, .NET, Java, Perl, Python,..., and a bunch of ancient ones) . E.G. the yaAGC was what got me interested in NASSP.

When I saw how tightly, and how well the software simulated the real spacecraft (well enough to run the AGC with no mods!!!) - I was hooked - I had wanted to re-build the AGC for a long time - only to find that someone had beaten me to it (and who had also done most of the archaeology).
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #14 on: January 19, 2008, 08:22:29 PM »

The catch is that submitting to sourceforge requires some manual work.

Let me give you the rundown of what an automated script COULD do, and what it can't:

Collect a daily CVS snapshot and tar/zip it (zip is preferred as it is supported out of the box by windows XP and up). Can be automated.
Post tar/zip to ftp://upload.sourceforge.net/incoming/ (anonymous FTP access, upload only).  Can be automated.
Update Sourceforge page with latest snapshot.  Must be done manually.

If you think you could help with this, I think I speak for everyone on the team by saying we'd love to have you onboard.  I know you already contribute a lot to the Apollo experience with the reports you are doing, but you have expressed a need that none of us are readily able to fill.

If you're interested, we'd simply need to get you added as a developer on sourceforge (Tschachim can take care of that) and then show you how to use the sourceforge release system.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!