Two process problem?

[Ross Jekel]

Thanks for the ideas. I tried creating a new repository object every time 
and I got the same behavior. Looking at the code, I couldn't see why it 
wouldn't work even with a long-lifetime object since in localrepo.py the 
lock function does a self.reload on acquisition: 

   def lock(self, wait=1):
       return self.do_lock("lock", wait, acquirefn=self.reload,
                           desc=_('repository %s') % self.origroot) 

   def reload(self):
       self.changelog.load()
       self.manifest.load()
       self.tagscache = None
       self.nodetagscache = None 

That seems to me to be the correct behavior. If this reload code is correct, 
then one might conclude that the locks are released too early on the side 
that made the last change (i.e. other processes can get the lock and reload 
before all changes were committed). 

Ross 


Bryan O'Sullivan writes: 

> On Wed, 2006-06-21 at 15:02 -0700, Ross Jekel wrote: 
> 
>> I'm using the mercurial code directly from python programs that I'm using to 
>> create a version controlled directory of RSS documents that get updated. 
> 
> If you're running two processes with long lifetimes concurrently, it's
> possible that each has a long-lived localrepository object that is not
> seeing the updates made by the other. 
> 
> Unless you're explicitly dropping and recreating the repo object for
> every commit (which you say you are not), I don't believe there's any
> explicit checking done in the internals to see if someone else modified
> the backing files that are used. 
> 
> A short-term fix would be to create a new localrepository object every
> time you want to do something. 
> 
> Alternatives that would involve more work could be as follows: 
> 
>      1. Have one thread/process own the localrepository object, such
>         that it does all reading and writing on behalf of the two
>         processes you have now.  Obviously a pain in the ass.
>      2. Add a method to mercurial.revlog that does a stat of the
>         backing .i and .d files, and reloads from them if they've
>         changed since the last read. 
> 
> Obviously, option #2 is more desirable, and wouldn't incur any overhead
> unless (a) used and (b) something had changed. 
> 
> 	<b 
>