Sorry state of the rsync based CVS,replication

[Patrick Bihan-Faou]

Hi,

[...] Regarding the permission of the Attic subdirs in place

 > The development/ section of the FTP site is something I hadn't looked

> at before so it took me a little time to find what populates it and
> investigate a little.  I *think* the issue with the Attic directories
> not including world-read permissions was either an issue with a badly
> formed chmod(1) done a long time ago or an issue with the mechanism
> that populates that portion of the FTP site missing a umask setting
> in the script that does it some time back in history (it's there now).
> Not all of the Attic directories had the wrong permissions, it seemed
> to stop some time in 2007.
>
> I adjusted the permissions on ftp-master so hopefully this issue is
> fixed.  However ...
>

Great news. I'll check various rsync source later and see if the 
situation improves.


>> We are moving to svn and svnsync for the freebsd source tree (and I am
>> happy with this), but the ports do not seem to be available using SVN
>> (or not in a documented way).
>>
>> Can something be done to restore RSYNC mirroring of the CVS tree to a
>> working state ?
> The FTP site desperately needs to go on a diet so we're poking around
> to see if there is some stuff that can be dropped.  This section of
> the site is a candidate for being removed.  As you say the ports are
> not available in SVN but I'm curious why you use the content from the
> FTP site instead of just using a CVSUP mirror.  Is there some benefit
> to it?  We would sort of like to stop providing this as part of the
> FTP site if there really isn't any benefit to it over using the
> cvsup mirror infrastructure which won't be going away any time soon.
>

The benefit is organisational to us. We did use cvsup in the past but it 
has been a pain to maintain as all the other external sources we keep in 
sync with use rsync. That combined with the requirement for m3 etc. for 
the sole purpose of syncing the CVS tree when there are alternatives 
(rsync for the freebsd cvs tree and more recently svnsync) made the 
switch to rsync a no brainer (note that this decision was taken long 
before csup came to life).

Don't take this as flamebait, because I have no intention in starting a 
war on this particular issue, but as good as cvsup is, this is 
unfortunately a fairly isolated tool that, from my prospective (which is 
necessarily biaised and incomplete), does not offer any feature 
compelling enough to prefer it over rsync in our case. That position is 
by essence just a personal view, applicable to me only and not to 
anybody else. Also I have to admit that now that the m3 dependency is 
gone with csup, it becomes easier to return to it.

Now if the plan is to eliminate rsync CVS mirroring (and I am in no 
position to criticize such a decision that is very well justified in 
your mail), we will of course adapt and go to one of the supported 
methods for CVS tree mirroring. If this means cvsup only, then we will 
do it without any hard feeling. I already figured that we must be almost 
the only ones to use rsync for CVS tree mirroring (otherwise that issue 
would have been detected and fixed a long time ago), and I don't expect 
(nor demand) the project to maintain a service for just one user, this 
would be ridiculous and unreasonable.

Anyways, thank you very much for taking the time to look at this issue 
and hopefully having fixed it. This is really greatly appreciated.

Best regards,

Patrick.