Problem with remote repository

[Peter Williams]

Peter Williams wrote:
> Matt Mackall wrote:
>> On Fri, 2009-05-29 at 01:36 +1000, Peter Williams wrote:
>>> Attempting to push changes to the gwsmhg repository on sourceforge I get:
>>>
>>> [peter at mudlark gwsmhg.ssh]$ hg push
>>> pushing to ssh://peter_ono@gwsmhg.hg.sourceforge.net/hgroot/gwsmhg
>>> searching for changes
>>> remote: abort: Permission denied: /hgrepo/g/gw/gwsmhg/.hg/journal.dirstate
>> When Mercurial gives you an error like that, it's coming directly from
>> the kernel. The effective user can't access the file. If the error looks
>> bogus, that only means you haven't looked hard enough, because the error
>> is undeniably real.
>>
>> Make sure you've checked all your assumptions about:
>>
>> - what user is effective
>> - what the file permissions are
>> - what the group permissions are
>> - what the directory permissions are  <- probably where your problem is
>> - how the filesystem is mounted
>> - what additional restrictions like ACLs or SELinux are in effect
>>
> 
> It's hard to properly check most of these things in the actual 
> repository because you can't access it directly but only via a copy 
> obtained using adminrepo and I suspect that the ownerships in that copy 
> don't necessarily reflect those in the real repo.  I had a similar 
> problem when I used adminrepo to add a hgrc file (with descriptions 
> etc.) to the repo and hg didn't like the file (called it suspicious) 
> because of its ownerships so I removed it.  I raised the problem with 
> sourceforge and they admitted that it was a bug and would look into it 
> (but I haven't heard anything since).  I'll raise the issue again now 
> using this problem as an example but I thought that I should check that 
> it wasn't a hg problem first as the names of the files in .hg there were 
> different to what I see here.  Is this a hg version issue?
> 
> Thanks for the help,
> Peter
> PS I don't know why we can't have direct access to the repo.  The 
> adminrepo thing was (apparently) originally introduced for cvs 
> maintenance where it may have been necessary (due to cvs's design 
> requiring one CVSROOT for all projects) but I can't see why it's 
> necessary for hg.

More on this.  I tried one more thing.  I used adminrepo to get a copy 
of the repo then used adminrepo to save it unchanged and this fixed the 
problem (previously I discarded the copy rather than saving it as I had 
changed it with the "hg rollback" command).  So I'm assuming that when 
adminrepo saved the copy it fixed the permissions.  I'll still report 
the problem to sourceforge but thought other (potential) sourceforge 
users on this list might appreciate knowing a workaround.

Cheers
Peter
-- 
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce