On Sun, Oct 27, 2013 at 9:01 PM, Zoom.Quiet <[email protected]> wrote:

2013/10/28 Edward K. Ream <[email protected]>:


> No.  The local cache is just a detail :-)  It merely needs to remember the
> files *with* sentinels **on Nancy's local machine.**  SCCS repository
> *never* sees the cache.  Only Nancy's push/pull hooks see the cache.
>

- the ~/.leo dir? sure, is the right space!
- but, the @shadow algorithm is usage between who?
- i guess just only can base the local user file and the lastest
ver
s
ion in SCCS ?

The @shadow algorithm is applied just before pushing a new version of one
of Nancy's files, say x.py.  Therefore the input to the @shadow algorithm
is:

1.  The cached version of x.py  This is the latest version of x.py that was
pulled from SCCS.  It contains sentinels.  In @shadow terminology, this is
the **private file**.

2. The version of x.py that Nancy is pushing.  This file is in Nancy's
local SCCS repository.  This file contains no sentinels. In @shadow
terminology, this is the **public file**.

- so this ways is perfect for DVCS but svn/csv/vss etc. Center VCS is not
good.

I believe this scheme will work for any kind of SCCS because the hooks
only work on a) the local repository and b) the local cache.

ok all clean!
- wait the brz first show us the prototype hooks
- just need know how call the @shadow algorithm from Leo
- in fact, this @shadow algorithm is very useful for other action,
etc. co-writing system

I don't have time to do a prototype now.  Here are the places containing
relevant code:

- leoShadow.py contains the fundamental @shadow algorithm plus quite a bit
of support code.

- leoAtFile.py contains the code actually reads and writes @shadow trees:
See at.readOneAtShadowNode and at.openFileForReading.

The at.atShadow ivar is set True in the init code for @shadow trees, so
searching for atShadow will show you the special-case code involved.  This
code is tricky, as you will see.

- I have been saying that we can ignore the details of the cache as far as
the *design* of this scheme goes, but the actual code is non-trivial.

The leoCache.py file contains the fundamental caching code that Leo uses to
cache files. Using this code is *very* tricky.  Here is the relevant code
from at.read::

    if fromString:
        s,loaded,fileKey = fromString,False,None
    else:
        s,loaded,fileKey = c.cacher.readFile(fileName,root)
    # Never read an external file with file-like sentinels from the cache.
    isFileLike = loaded and at.isFileLike(s)
    if not loaded or isFileLike:
        # if trace: g.trace('file-like file',fileName)
        force = True # Disable caching.
    if loaded and not force:
        if trace: g.trace('in cache',fileName)
        at.inputFile.close()
        root.clearDirty()
        return True

For the push hook, fromString will always be False.

It appears that at.isFileLike returns True is the file uses *old-style*
@file sentinels, so we can ignore this test.

So for the bzr push hook, the simplified code to get the cached file will
be::

    s,loaded,fileKey = c.cacher.readFile(fileName,root)
    if loaded:
        << use s as the contents of the private file >>

The fileKey is used later in at.read to write the newly-read contents of
the file back to the cache.  This write may not be strictly necessary, but
it would simplify the @shadow algorithm if Nancy pushes the file again
before pulling it.

To repeat, I don't have time to do this now.  I've given you the places
from which I would start.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to