Re: [Monotone-devel] Problems with _MTN/tmp

[Rob Schoening]

The CC mvfs filesystem definitely gets points for being clever, especially being able to access arbitrary branches / versions using simple filename extensions.

 

But as you alluded to, it is too clever for its own good in a lot of ways.  

 

Beware any VCS that needs to run in kernel mode!

 

The level of effort of implementing something like this has always seemed an order of magnitude greater than the VCS itself.  But I wonder if some kind of virtual filesystem could be made generic enough to be shared across a variety of tools...version control, content management, etc.

 

I'm not suggesting that it be done here, or in response to this issue, or even at all...merely that it would make for an interesting project in and of itself.

 

RS
 

On 5/31/06, address@hidden <address@hidden> wrote:

Clearcase adds a new loopback filesystem to the kernel, which allows it to
track both managed (under CM) and view private files.

Dynamic views in clearcase are a wonder to work with, except for the
performance hit (which is often due to poor configuration of systems and
the lack of the solaris 'doors' functionality on Windows. Doors allow
cross process RPC calls within the same timeslice, so making calls to a
daemon much faster as there is no wait on the scheduler)

On the other hand, clearcase snapshot views suffer all the same problems
as any non-managed workspace, but perform at native file system speed.

Joel

> On Tue, May 30, 2006 at 09:47:10AM +0100, Ian France wrote:
>> mtn: expanding selection 'h:com.example.newbranch'
>> mtn: expanded to '879ff04f5e5aed535f2c2fb3419393c32b451bf2'
>> mtn: selected update target 879ff04f5e5aed535f2c2fb3419393c32b451bf2
>> mtn: dropping somepath/somefile.java
>> mtn: dropping anotherpath/anotherfile.java
>> mtn: dropping anotherpath_but_a_directory_this_time_not_a_file
>> mtn: error: could not remove '_MTN/tmp/3'
>> mtn: error: Directory not empty
>>
>> Curiously, IMHO, the _MTN/tmp/3 directory contained a backup of one of
>> the files dropped above. i.e. anotherpath/anotherfile.java~
>
> I bet this error is easy to reproduce as:
>   -- put some unknown or ignored file inside a directory
>   -- update to a revision in which that directory has been removed
>
> The update will remove any versioned files contained in that
> directory before attempting to delete the directory, because any rev
> in which the directory has been removed no longer has those files in
> it (obviously).  But monotone won't know to touch any unknown or
> ignored files in the directory, so when it goes to remove it for real,
> they screw things up.
>
> Workspaces are annoying :-/.  This is another place where it'd be nice
> to be able to rollback a failed workspace modification.  I wonder what
> other systems do here.
>
> -- Nathaniel
>
> --
> "...these, like all words, have single, decontextualized meanings:
> everyone
> knows what each of these words means, everyone knows what constitutes an
> instance of each of their referents.  Language is fixed.  Meaning is
> certain.  Santa Claus comes down the chimney at midnight on December 24."
>   -- The Language War, Robin Lakoff
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>
>





_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel