monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) question


From: graydon hoare
Subject: Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions
Date: 15 Sep 2003 09:53:48 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Tom Lord <address@hidden> writes:

> it's a mixed bag and to belabor the hopefully obvious point I'm
> confident that you'd feel the same way about arch

I suppose so. we will probably not do much more than share ideas at
this point, but I'm ok with that.

> you would be increasing, not decreasing vulnerability in really
> serious ways).

which sorts of vulnerability do you see?

> The rename-detection heuristics Graydon described have some uses,
> certainly -- but those uses are limited.

I think our rename handling is adequate, and is anyways a secondary
bit of information. the primary information -- which exact version of
a tree you are talking about -- is quite safe whether we detect a
rename as a rename or an add+delete.

> It sounds (Tromey's reply) like there will be no principled
> separation of patching from history that's stored only the meta-data
> of repositories -- that's a big mistake

I think you have misread. delta storage is handled by a dumb
SHA1-based subsystem which knows nothing about filenames, metadata or
other history. 

> A comparison of two manifests (at least as documented in the .info
> file) can never (accurately) yield "directory FOO was renamed" 

we treat directories as a side-effect of file paths. when a directory
is renamed, it is seen as a bunch of file paths changing. empty
directories are ignored.

> Overall -- it's a relatively monolithic design in a design space that
> factors nicely and usefully into independent parts.

the tool is monolithic. I consider that a selling point. but the
design is quite separated out: 

  - SHA1s denote file versions 
  - manifest SHA1s denote tree versions
  - every other bit of metadata (including the ancestry graph) is
    built from independent cryptographic certificates.

> Relying on history that way has significant operational drawbacks
> (i.e., _slow_) and semantic drawbacks (i.e., too many intertwingled
> factors).

the only present facts are file versions, their assignment to paths,
and a bag of certificates. renaming is a historical fact, not a
present fact. so I think it natural to calculate renames only as
needed when looking through history.

-graydon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]