Good and proper this time - not only CVS but the whole web site.
I'm very ready to move off - just evaluating ways to go now.
aarrrgggghhhhh!! 
Nuf said
Nuf said
The developer CVS and the SF website are working fine for me. Must have been just a blip.
Are you perhaps being a little hasty in wanting to move away? The large CVS outage has been a major problem for progress on v1.6 but I'm prepared to bet that the people at sf.net have learnt an awful lot from it! Once the full service is restored (inc anon CVS), then it will probably be one of the more robust services available!
Perhaps simply having a backup service (whether CVS, SVN, git, whatever) which tracks the sf.net CVS, and can be brought into action in case of outages, could be considered?
Are you perhaps being a little hasty in wanting to move away? The large CVS outage has been a major problem for progress on v1.6 but I'm prepared to bet that the people at sf.net have learnt an awful lot from it! Once the full service is restored (inc anon CVS), then it will probably be one of the more robust services available!
Perhaps simply having a backup service (whether CVS, SVN, git, whatever) which tracks the sf.net CVS, and can be brought into action in case of outages, could be considered?
I don't think it's hasty, no, this has been building for a while with increasing problems over the past year. They seem to be understaffed or something. It was down for at least several hours this morning.
Just having a secondary master tracking SF as a primary is not going to work well, because everyone needs to then switch back and forth, and we need to resynch everything without losing anything.
I'm seriously considering running a central code.moodle.com (again) just for developers (might be a good time to change to SVN or something else too), and using other sites as mirrors for anonymous CVS (perhaps even Sourceforge could still handle most of that anonymous traffic).
The main obstacle to that plan is a cost (for me) of about US$5000/year. We might have to have a little funding drive soon.
Just having a secondary master tracking SF as a primary is not going to work well, because everyone needs to then switch back and forth, and we need to resynch everything without losing anything.
I'm seriously considering running a central code.moodle.com (again) just for developers (might be a good time to change to SVN or something else too), and using other sites as mirrors for anonymous CVS (perhaps even Sourceforge could still handle most of that anonymous traffic).
The main obstacle to that plan is a cost (for me) of about US$5000/year. We might have to have a little funding drive soon.
Only $5.000/year?
Doing a quick calculation (I'm really skillful with that sort of things) it seems that all you need is, uhm.... 100 payments of $100 to be able to have the service online during, at least, two years and only 50 payments of $100 to have our own versioning server over 12 months! (less payments if some rich moodler want's to contribute with more than $100, of course
).
More yet, every $100 payment will help to maintain the service over ONE COMPLETE WEEK! Amazing! What about to display somewhere in the versioning server something like "This week this service is working thanks to AEIOU". And the complete calendar of donors too.
Ah, sorry, I'm dreaming...(if I start I cannot stop to say silly things).
I would vote (and donate) for it. Exactly now!
Will we reach the magical number? Who knows...
Ciao
Doing a quick calculation (I'm really skillful with that sort of things) it seems that all you need is, uhm.... 100 payments of $100 to be able to have the service online during, at least, two years and only 50 payments of $100 to have our own versioning server over 12 months! (less payments if some rich moodler want's to contribute with more than $100, of course
More yet, every $100 payment will help to maintain the service over ONE COMPLETE WEEK! Amazing! What about to display somewhere in the versioning server something like "This week this service is working thanks to AEIOU". And the complete calendar of donors too.
Ah, sorry, I'm dreaming...(if I start I cannot stop to say silly things).
I would vote (and donate) for it. Exactly now!
Will we reach the magical number? Who knows...
Ciao
Im all up for the donation drive. However the "sponsorship" aspect could get messy.
I concur that the best way of guarranteeing stability to host it ourselves. Having our own version of a CVS running would be a good way of doing it.
I concur that the best way of guarranteeing stability to host it ourselves. Having our own version of a CVS running would be a good way of doing it.
When I do an Update List through tortoise, the 1.6 stable branch still does not show up in my dropdown.
I'm curious, are you paying a fee for the cvs through sourceforge?
I'm curious, are you paying a fee for the cvs through sourceforge?
Well if things go for that direction I'm willing to donate 5/month, which is not much and maybe more at the end of the year if my wife doesn't find out
I know you know Eduforge.org has the doors open for Moodle development hosting and you can call me direct to my mobile if there's a glitch. (Ouch!)
You are totally right about primary/secondary CVS -- it just doesn't work. No way of doing that right given the CVS protocol and the internal storage format. Right now Eduforge.org supports CVS and SVN... and GIT support is one rainy weekend away (or just someone asking for it!).
Using something more distributed (plenty of choice nowadays: git, monotone, mercurial, etc) means it is possible to spread the load. If the SF.net guys let you run rsynn on their servers, you could have developer CVS on Moodle.org or Eduforge,org and push using rsync to the read-only anon CVS server. But I don't think they'll do that.
You are totally right about primary/secondary CVS -- it just doesn't work. No way of doing that right given the CVS protocol and the internal storage format. Right now Eduforge.org supports CVS and SVN... and GIT support is one rainy weekend away (or just someone asking for it!).
Using something more distributed (plenty of choice nowadays: git, monotone, mercurial, etc) means it is possible to spread the load. If the SF.net guys let you run rsynn on their servers, you could have developer CVS on Moodle.org or Eduforge,org and push using rsync to the read-only anon CVS server. But I don't think they'll do that.
Thanks for the very kind offer, but I really want to have the primary server as a moodle.org site run by moodle.com. I don't think it's going to be much maintenance once it's all set up with RAID, backups etc. And the bandwidth of even 300 developers is not that high really.
I don't want to supply anonymous CVS though! Unfortunately I have no statistics on anonymous CVS use from Sourceforge, but I'm guessing it could be a fair amount. A list of mirrors would be good to share the load, with the central server synching to them every hour or two.
With Sourceforge, I was not thinking of using rsync (because we might be using SVN, even) but rigging a script up to automatically check all changes into their CVS repository via normal CVS commands
Would Eduforge be interested in running a mirror to provide anonymous CVS? (Hopefully not implemented by a hack such as the above one
Anyone else think they might be interested in providing some of that anonymous bandwidth for Moodle users worldwide? Any Universities volunteering? I would like to have at least two or three candidates lined up before embarking on this kind of structure.
I don't want to supply anonymous CVS though!
With Sourceforge, I was not thinking of using rsync (because we might be using SVN, even) but rigging a script up to automatically check all changes into their CVS repository via normal CVS commands
Would Eduforge be interested in running a mirror to provide anonymous CVS? (Hopefully not implemented by a hack such as the above one
Anyone else think they might be interested in providing some of that anonymous bandwidth for Moodle users worldwide? Any Universities volunteering? I would like to have at least two or three candidates lined up before embarking on this kind of structure.
By the way, have you tested new sf.net svn service? It seems more stable than cvs and may be a solution.
The Sourceforge support tracker seems to have plenty of problems related to even SVN.
They may well be all sorted out sooner or later (and I hope they are!) but the point is that they may have problems again in the future, and we'll be helpless yet again.
They may well be all sorted out sooner or later (and I hope they are!) but the point is that they may have problems again in the future, and we'll be helpless yet again.
> Any Universities volunteering?
What should we ask for? Do our system adminstrators need to run some special CVS software on the server?
Tim
Yes, they need to run a CVS server, plus rsync at least (to mirror the server files) and/or possibly some other scripts to convert the main files into CVS if the main server doesn't end up being CVS.
I've not yet looked into how an SVN or GIT system can be converted into a read-only CVS repository - I'm assuming it's possible though.
I've not yet looked into how an SVN or GIT system can be converted into a read-only CVS repository - I'm assuming it's possible though.
Now that I've made some of my own code changes to 1.6 dev and can't update them to 1.6 stable it's pretty frustrating.
I certainly wouldn't mind paying a some sort of fee for this -- a monthly access fee or bandwidth fee of some sort
.
I certainly wouldn't mind paying a some sort of fee for this -- a monthly access fee or bandwidth fee of some sort
.
Any estimation on the required bandwidth?
Saludos. Iñaki.
Saludos. Iñaki.
"I've not yet looked into how an (expletive deleted) or GIT system can be converted into a read-only CVS repository - I'm assuming it's possible though."
There is a git utility (git-cvsserver) that acts as an anon cvs server so end-users can get a cvs checkout straight from GIT. Have also been talking with MartinD of generating a static CVS repo from the GIT repo, so it can be mirrored.
Using git-cvsserver it would be easier to run the replication, but it would be harder to setup several mirrors. Will have to think about it a bit. Exporting the static CVS repo is "easier" but needs a new utility that I am kind of thinking about and may write.
What I am a bit unsure is whether there's any interest in still allowing commits via git-cvsserver so that translators can commit directly (which is supported via ssh).
Does git-cvsserver support writes already? It could be nice as an option for developers with simple needs.
Otherwise, were we to use GIT, what options would there be for making it easy for, say, translators on windows to check in their work?
Otherwise, were we to use GIT, what options would there be for making it easy for, say, translators on windows to check in their work?
Yes Martin, this is very important. And we translators have to have access to the latest code, in order to test what we're working on.
Don't forget us !
Don't forget us !
Eduforge.org can host anon CVS for Moodle No problem! (We had a brief Skype chat with MartinD, some notes follow).
We discussed pushing it out regularly via rsync. Given that the rsync protocol is a bit expensive to run over very large directory trees, we can probably do something more CVS specific. Like optimise things with a bit of Perl/Bash to read CVSROOT/history and figure out what parts of the repo have changed recently. Or use cvsup.
The network protocol and storage format or CVS are so broken that it's not funny
To answer Timothy about what would be required:
Disk space - I think an unpacked moodle cvs repo is now ~800MB
Bandwith - how much? I dunno!
A cron entry that calls a bash/perl script that will fetch updates via rsync. Or maybe cvsup.
Martin,
Could you contact me re: details of your proposal. I may have the space to provide an rsync'd mirror but would like to know what I may be letting myself in for.
JR
Could you contact me re: details of your proposal. I may have the space to provide an rsync'd mirror but would like to know what I may be letting myself in for.
JR
Anyone else think they might be interested in providing some of that anonymous bandwidth for Moodle users worldwide? Any Universities volunteering? I would like to have at least two or three candidates lined up before embarking on this kind of structure.
I think we (Mondragon Unibertsitatea) can provide this kind of infrastructure in a month or two.
We have a spare machine with plenty of disk (100 GB or so) in RAID5, and 100 Mbps to the Internet. Processor is not ultra-poweful (Athlon XP 2200+) and RAM is a bit low (512 MB) but I think it would we enough for a CVS anonymous mirror right now.
On the other hand, I think we could get a newer, more powerful
machine (bi-proc, lots of RAM, redundant power-supply, etc) in 6 months or so.
Would this be enough?
Saludos. Iñaki.
Hehe,
just to to put one's finger on the sore spot
...exactly 1 minute ago:
Hopefully, it will be a short-outage.
Ciao
just to to put one's finger on the sore spot
Traceback (most recent call last):and since then:
File "/cvsroot/moodle/CVSROOT/syncmail", line 694, in ?
main()
File "/cvsroot/moodle/CVSROOT/syncmail", line 687, in main
blast_mail(config, changes)
File "/cvsroot/moodle/CVSROOT/syncmail", line 303, in blast_mail
resp = conn.sendmail(address, config.people, s.getvalue())
File "/usr/lib/python2.3/smtplib.py", line 687, in sendmail
raise SMTPRecipientsRefused(senderrs)
smtplib.SMTPRecipientsRefused: {'moodle-cvs@lists.sourceforge.net': (451, 'Temporary local problem - please try later')}
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages if any)
Hopefully, it will be a short-outage.
Ciao
Watch out! The commit succeeded at least partially, but the mailout failed and your cvs client got told that the whole thing failed.
So the cvs checkout in your machine probably thinks the files are uncommitted, while the server has seen at least some of the commits. Maybe.
Make sure you do cvs status on those files to see WFT cvs thinks the situation is.
What a broken network protocol...
Hey,
the commit was successful (I omitted the previous lines in my message above) but just when the email was being generated, something crashed in SF servers (and continue exactly the same now - 3 hours later).
Also, I want to publicly declare that my commit didn't contain anything dangerous (at least no more than my usual commits).
Although, uhm, perhaps my commit broke the entire SF CVS! Wow!
If so, sorry developers! 
Am I the only one affected (SF status page doesn't show anything new) or is it the same for you?
What a broken server...
the commit was successful (I omitted the previous lines in my message above) but just when the email was being generated, something crashed in SF servers (and continue exactly the same now - 3 hours later).
Also, I want to publicly declare that my commit didn't contain anything dangerous (at least no more than my usual commits
Although, uhm, perhaps my commit broke the entire SF CVS! Wow!
Am I the only one affected (SF status page doesn't show anything new) or is it the same for you?
What a broken server...
Today (Thursday - May 11th) I haven't been able to access CVS since yesterday. Is this me, or is this a general problem?
mike
mike
General problem, same here
From SourceForge Status Page:
From SourceForge Status Page:
(
2006-05-10 04:43:14 -
Project CVS Service )
As of 2006-05-09 the developer CVS
server had a disk-failure. As the new CVS infrastructure is in
its final phases of rollout, we'll be deploying it, in place of
the current infrastructure, by end of week. We'll be sending
out an email to project administrators with further details
later in the day, regarding how to access the new CVS servers
and the changes that occurred with the new infrastructure.
Oh it's general, baby, a general PITA.
From sourceforge today. Let's hope it goes well, because we need them for the short term.
Greetings,
You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.
The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.
The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.
Summary of changes, effective 2006-05-12:
1. Hostname for CVS service
Old: cvs.sourceforge.net
New: PROJECT_UNIX_NAME.cvs.sourceforge.net
This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gaim co gaim
would be changed to
cvs -d:pserver:anonymous@gaim.cvs.sourceforge.net:/cvsroot/gaim co gaim
2. ViewCVS
We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.
3. Sync delay
Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.
New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.
Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.
4. Read-only rsync service
As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.
All projects should be making regular backups of their CVS repository
contents using this service.
5. Nightly tarball service
Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.
We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.
6. Points of failure
In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.
Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).
Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.
This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires.
Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04
Thank you,
The SourceForge.net Team
Greetings,
You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.
The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.
The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.
Summary of changes, effective 2006-05-12:
1. Hostname for CVS service
Old: cvs.sourceforge.net
New: PROJECT_UNIX_NAME.cvs.sourceforge.net
This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gaim co gaim
would be changed to
cvs -d:pserver:anonymous@gaim.cvs.sourceforge.net:/cvsroot/gaim co gaim
2. ViewCVS
We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.
3. Sync delay
Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.
New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.
Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.
4. Read-only rsync service
As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.
All projects should be making regular backups of their CVS repository
contents using this service.
5. Nightly tarball service
Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.
We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.
6. Points of failure
In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.
Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).
Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.
This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires.
Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04
Thank you,
The SourceForge.net Team
Thanks for the update Martin . . . great news 
Do you know what the ramifications are for cvs update? Been using it but never looked into it as to how it works, guessing whatever site it's referencing now no longer exists based on the example given above re hostnames.
Regards
Harry
Do you know what the ramifications are for cvs update? Been using it but never looked into it as to how it works, guessing whatever site it's referencing now no longer exists based on the example given above re hostnames.
Regards
Harry
Good news overall. Though I have to say pfffft (where is the emoticon when I need it?) to:
This change will require new working copies to be checked out of all
On mac/linux, backup your checkout just in case, and do
$ find . -type f -name Root -print0 | xargs -0 perl -pi -e 's/cvs\.sourceforge/moodle\.cvs\.sourceforge/'
On Windows, there are some reasonable file-renaming tools. Or there used to be 6 years ago, last time I used one of those machines
Martin, thank you very much for your time saver. I checked first if other sourceforge cvs repositories on my harddisk suddenly change their identity to Moodle with your one-liner
I hope we can continue with business as usual when they have rolled out the new infrastructure today.
Urs
Thanks for the tool! I would never have known how to script that as a one-liner...
For Windows, there is a great free program called Rename Master for renaming files.
Oops! Did I say file renaming? I meant massive search and replace 
Sorry about the confusion.
Urs, Dan, No Problem! Happy to be able to help!
Urs, Dan, No Problem! Happy to be able to help!
Windows shell and command line tools still pretty much suck as they did 6 years ago
But I've used "GNU utilities for Win32" which has some common GNU utils ported to windows (http://unxutils.sourceforge.net/). Sometimes perl helps too (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl)
But I've used "GNU utilities for Win32" which has some common GNU utils ported to windows (http://unxutils.sourceforge.net/). Sometimes perl helps too
On Windows you can use WinGrep. I just replaced cvs.sourceforge.net by moodle.cvs.sourceforge.net in all files with the name Root in my sandboxes and everything is working fine again.
Hi Martin
Tried this on my server (using putty) but I get - $: command not found
Am I correct in thinking that
Regards
H
Tried this on my server (using putty) but I get - $: command not found
Am I correct in thinking that
$ find . -type f -name Root -print0 | xargs -0 perl -pi -e 's/cvs\.sourceforge/moodle\.cvs\.sourceforge/'Regards
H
I am not an expert here but I would suspect that the $ is just the prompt provided by Martin's unix shell at the start of a command line. It is not something you should type.
Hi Gustav
I tried it without the $ too and it just hung and did nothing.
Will try again.
Ooooops . . . looks like it might have worked when I thought it hung.
EDIT: Just tried again - no indication if it worked or not - thought I'd try cvs update anyway - came back with "Unknown host moodle.moodle.cvs.sourceforge.net." - note the extra moodle in there!
EDIT 2: Yep, it worked both times by the looks of it, CVS Root file now contains ":pserver:anonymous@moodle.moodle.cvs.sourceforge.net:/cvsroot/moodle" WIll fix it up tomorrow.
Thanks gents
I tried it without the $ too and it just hung and did nothing.
Will try again.
Ooooops . . . looks like it might have worked when I thought it hung.
EDIT: Just tried again - no indication if it worked or not - thought I'd try cvs update anyway - came back with "Unknown host moodle.moodle.cvs.sourceforge.net." - note the extra moodle in there!
EDIT 2: Yep, it worked both times by the looks of it, CVS Root file now contains ":pserver:anonymous@moodle.moodle.cvs.sourceforge.net:/cvsroot/moodle" WIll fix it up tomorrow.
Thanks gents
Oops! I did assume some unix commandline experience, so I didn't clarify things... here we go...
- Replace the . with the directory of your moodle checkout. The "dot" means "this directory where we are right now".
- It is silent. It won't report progress... it hasn't gone to la-la -land, it's just... not very communicative
- The leading $ sign is your shell prompt
- That command line has minor stupid side-effects with GNU xargs. To make it perfectly safe I should have said
--no-run-if-empty. Nothing bad though.
To fix your doubled-up moodle.moodle stuff, do
$ find moodle/checkout/dir -type f -name Root -print0 | xargs -0 perl -pi -e 's/moodle\.moodle\.cvs\.sourceforge/moodle\.cvs\.sourceforge/'
Cheers!
Martin, no "Oooops" required . . . I tend to learn by jumping in and breaking things (on a test install at least), I should've looked into it before just jumping in with both feet . . . one day I may change but unlikely 
Will fix the double Moodle when I get a chance . . . and maybe bookmark a few unix sites as well
Thanks again for your initial pointer and the fix to my little mistake and again to Gustav for his input . . . gotta love this community
Regards
H
Will fix the double Moodle when I get a chance . . . and maybe bookmark a few unix sites as well
Thanks again for your initial pointer and the fix to my little mistake and again to Gustav for his input . . . gotta love this community
Regards
H
I've been using this version, it allows you to re-run it without re-fixing anything already fixed:
It can be run from /home, say, to fix multiple sites at once.
find . -type f -name Root -print0 | xargs -0 perl -pi -e 's/\@cvs\.sourceforge/\@moodle\.cvs\.sourceforge/'
It can be run from /home, say, to fix multiple sites at once.
I've been using this version
It works for us propellerheads with SSH accounts... IIRC people with anon access have a ':' instead... so if MartinD's recipe doesn't work for you, try...
find . -type f -name Root -print0 | xargs -0 perl -pi -e 's/:cvs\.sourceforge/:moodle\.cvs\.sourceforge/'
In reply to Martin Dougiamas
Re: Sourceforge is down again - please help with checkout
by David Mudrák -
Hi,
it must be Friday or something but I simply can't see any mistake... Can you somebody, please? thank you
$ cvs -z3 -d:ext:mudrd8mz@moodle.cvs.sourceforge.net:/cvsroot/moodle co -r MOODLE_15_STABLE -d ./moodle-15-stable moodle
mudrd8mz@moodle.cvs.sourceforge.net's password:
Could not chdir to home directory /home/users/m/mu/mudrd8mz: Transport endpoint is not connected
Cannot access /cvsroot/moodle/CVSROOT
No such file or directory
mudrd8mz@moodle.cvs.sourceforge.net's password:
Could not chdir to home directory /home/users/m/mu/mudrd8mz: Transport endpoint is not connected
Cannot access /cvsroot/moodle/CVSROOT
No such file or directory
it must be Friday or something but I simply can't see any mistake... Can you somebody, please? thank you
In reply to David Mudrák
Re: Sourceforge is down again - please help with checkout
by Mike Churchward -
Hmmm. I'm getting the same error. 'Cannot access /cvsroot/moodle/CVSROOT'. It's accessing the right repository though.
Anybody?
mike
Anybody?
mike
In reply to Mike Churchward
Re: Sourceforge is down again - please help with checkout
by David Mudrák -
Seems there was some problem at sf.net. It works now. But I am getting another error message:
cvs commit: cannot find pre-commit filter `/cvsroot/sitedocs/CVSROOT/cvstools/cvs_acls': No such file or directory
Will try to wait, probably they are still working on the new CVS
cvs commit: cannot find pre-commit filter `/cvsroot/sitedocs/CVSROOT/cvstools/cvs_acls': No such file or directory
Will try to wait, probably they are still working on the new CVS
In reply to David Mudrák
Re: Sourceforge is down again - please help with checkout
by Mike Churchward -
Semi-working now. I can access, but I can't commit. (I had a girlfriend who said that about me once ).
mike
).mike
In reply to Mike Churchward
Re: Sourceforge is down again - please help with checkout
by David Mudrák -
FYI - I modified the docs for Administrator and Developer CVS to include the revised moodle.cvs.sourceforge.net syntax.
Well, this explains why I have not been able to get on the last few days!
I went to the CVS page in the download area and got the commands there and updated for what it sounded like they needed but I get this:
# cvs -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle login
Logging in to :pserver:anonymous@moodle.cvs.sourceforge.net:2401/cvsroot/moodle
CVS password:
cvs login: failed to open /root/.cvspass for reading: No such file or directory
cvs [login aborted]: fatal error: exiting
I decided just for chuckles and grins to do the next command and lo, and behold it works!
Thought I would post this so others would know.
Thanks!
Jenny
A big thank you to you Gustav. I was able to follow the directions in your post and get things working again.