On Wed, Mar 25, 2009 at 5:19 PM, Ville M. Vainio <[email protected]> wrote:
> > On Wed, Mar 25, 2009 at 11:59 PM, Edward K. Ream <[email protected]> > wrote: > > > want the public files. To make this scheme work, we would want a way > > to force users to commit public/private pairs of files in synch. This > > is possible in principle, but I'm not sure how easy it would be. In > > the worst case, Leo users could fall back on @auto, but we really > > would rather avoid that sad eventuality. > > Hashing to rescue! For file foo.py ver 3, we have a private version > 2368237aaee.txt.py. The name is the hash digest of contents of foo.py. > So, when you open foo.py, leo will look up the right private filei in > a priv file repo. People can commit their private files a bit > off-sync, as long as the right files end up in the repo at some point. Thanks for this: it looks like an immediate proof that we don't have to worry much about syncing public and private files. In contrast, checksums don't help at all when trying to create unbreakable links. If a checksum fails, it tells us nothing about where we might find the changed node. > > > BTW, it might be good for this case to put all files containing > > sentinels in a single place, so as not to overly pollute the directory > > structure in the repository. > > Yeah, that's the repo :-). Like we have .bzr, we can have > .leo_structure in project root. If you send out a leo tree somewhere > (release), you will also ship that dir. GC can be done every now and > then. > > > Unless I am horribly mistaken, @file! promises to relegate the > > (absolutely essential) sentinels to the background for almost all use > > cases. In effect, we get all the advantages of @thin nodes in all use > > cases. > > Why not keep calling it @shadow, becase that's what it still remains? > The difference is that shadow files are also public files now. I'm a bit shocked that you haven't found a glaring hole in the idea. I'm starting to confront how good this scheme might be. For example, it looks like @file! does not need to care whether the public or private files are committed to bzr. As another example, the docs will no longer have to describe the 9 (!) ways to create external files. Obviously, we can call @file! anything we want. My thinking is that the new @file might actually be all there is, so @file would seem to be the clearest choice. I'm not wild about @shadow, because @file! is an amalgam of @thin, @auto, @shadow and maybe even @edit. We probably should leave the final name for later, after all the details become clearer. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
