[Top][All Lists]
[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
- [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, Tom Lord, 2003/09/12
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, graydon hoare, 2003/09/12
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, Tom Tromey, 2003/09/14
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions,
graydon hoare <=
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, Tom Lord, 2003/09/15
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, graydon hoare, 2003/09/15
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, Tom Lord, 2003/09/15
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, graydon hoare, 2003/09/15
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, Tom Lord, 2003/09/21
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, graydon hoare, 2003/09/21
- Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions, Tom Tromey, 2003/09/15