Re: [fuse-devel] [ANNOUNCE] Cascade

[Matt C. <mat...@co...>]

Brian,

You're still working in a local "working copy" (it's not a copy thanks to
the file system, but it looks like one).  It's not as though, when you edit
a file and save, it is immediately committed to the repository.  No one else
sees your edits until you explicitly commit them.

Commits still require an explicit "commit" command.  Also, first, you
"checkpoint" your changes (upload them onto Cascade Manager), and they are
tested to make sure they won't break the build, etc.  Only if everything
passes are you allowed to go ahead with the commit.  You can think of a
"checkpoint" as being sort of like a patch submission.

On Wed, Sep 10, 2008 at 12:59 PM, Brian Wang <ywa...@ho...> wrote:

>  Matt
>
> Thanks for explaination.
>
> What I really meant is why do you need SVN if your FS edit the files in the
> repository directory? would that defeat all the purpose of using a source
> control application like SVN? Why is it different from a shared NS/CIFS
> mount everyone can edit the files on?
>
> Brian
>
>  ----- Original Message -----
> *From:* Matt Craighead <mat...@co...>
>   *To:* Brian Wang <ywa...@ho...>
> *Cc:* fus...@li...
> *Sent:* Wednesday, September 10, 2008 11:57 AM
> *Subject:* Re: [fuse-devel] [ANNOUNCE] Cascade
>
>  Hi Brian,
>
> Cascade isn't intended to replace your existing repository -- it's a new
> way to access an existing repository.
>
> There's not much sense in my writing a brand new repository.  A lot of
> other people have already spent a lot of time on solving that problem.
> Also, convincing people to move their mission-critical data over to a new
> repository is a tough sell.
>
> On Wed, Sep 10, 2008 at 12:47 PM, Brian Wang <ywa...@ho...> wrote:
>
>> just curious, then why do you need SVN?
>>
>>
>> ----- Original Message ----- From: "Matt Craighead" <
>> mat...@co...>
>> To: <fus...@li...>
>> Sent: Wednesday, September 10, 2008 11:37 AM
>> Subject: [fuse-devel] [ANNOUNCE] Cascade
>>
>>
>>   Hi all,
>>>
>>> Thanks for creating FUSE!  I've found it to be very helpful.
>>>
>>> I've released a commercial product, Cascade, that makes use of FUSE (and
>>> MacFUSE): http://www.conifersystems.com/cascade/  One of its components,
>>> Cascade File System, lets you view and edit Subversion and Perforce
>>> repositories without needing to "check out" a local copy of the
>>> repository
>>> files on your hard drive, so setting up a tree is an O(1) operation
>>> regardless of the size of the repository.  Having worked on projects
>>> where I
>>> needed many gigabytes of files from the repository, well -- I wish I had
>>> this product back then. :)  In addition, the results of automated
>>> builds/tests on your repository are exposed through the file system, too,
>>> so
>>> when you set up a tree it can effectively come "prebuilt".  You can see a
>>> walkthrough of how this all works in the Flash demo on my web site.
>>>
>>>
>>> I do have some bugs in FUSE to report, though.  Off the top of my head:
>>>
>>> - It deadlocks if I do recursive FS access, i.e., my FS accesses itself
>>> (indirectly, in this case, through another process, although I'm not sure
>>> if
>>> that matters) as part of its implementation of a particular FS operation.
>>> I
>>> understand that infinite recursion would be bad news, and you certainly
>>> can't have more levels of recursion than you have threads -- I'm just
>>> talking about one level of recursion in this case.
>>>
>>> - I don't seem to be able to check the return value of fuse_main.
>>> fuse_main
>>> seems to return 1 even if the file system is shut down normally through
>>> fusermount.  I would expect that it should return 0 in the case of normal
>>> shutdown and nonzero only if something went wrong.
>>>
>>> - There is apparently no way to return an error from my init() function?
>>> I
>>> have a thread I need to create, and as the documentation explains, I am
>>> required to create threads in init() and not in main().  But, like any
>>> operation that allocates resources, creating a thread can fail.  (Of
>>> course,
>>> reporting an error from init() would only be useful if the previous bug
>>> was
>>> fixed, so I could look at fuse_main()'s return value to see whether the
>>> file
>>> system was able to initialize successfully.)
>>>
>>> - It would be nice if allow_other and default_permissions were the
>>> default
>>> settings.  I was somewhat surprised to learn that you have to set some
>>> special options to get "normal" Unix file system semantics.  I would
>>> think
>>> that normal Unix semantics (security based on permissions, uid, and gid
>>> returned by your FS in response to getattr) would be the default, and
>>> you'd
>>> have to explicitly override them if you wanted something different.
>>>
>>> - I've run into some issues with caching.  FUSE doesn't know about some
>>> of
>>> my special file system operations, and so it caches stale data.  This
>>> happens, for instance, after you update your tree to a new revision.
>>> Eventually the cache entries appear to time out, but in the meantime you
>>> get
>>> incorrect answers to certain FS operations, and it would be nice for
>>> performance if the cache didn't have to time out.  If nothing else, it
>>> would
>>> at least be nice to have a callback to tell FUSE to invalidate its cache.
>>>
>>> --
>>> Matt Craighead
>>> Founder/CEO, Conifer Systems LLC
>>> http://www.conifersystems.com
>>> 512-772-1834
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> fuse-devel mailing list
>>> fus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>>>
>>>
>>
>
>
> --
> Matt Craighead
> Founder/CEO, Conifer Systems LLC
> http://www.conifersystems.com
> 512-772-1834
>
>


-- 
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834