monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] newcomer (rude, but hopefully not to rude) questions


From: Tom Lord
Subject: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions
Date: Fri, 12 Sep 2003 14:35:29 -0700 (PDT)


I am, so far, just going on the .info file so I apologize if this is a
naive question or one that is the side-effect of out-of-date docs.

According to the .info file, a tree revision is defined as a set
within the domain:

        SHA1-signature * relative path

e.g.:

        71e0274f16cd68bdf9a2bf5743b86fcc1e597cdc  fs/namei.c

Isn't it a consequence of that that logically equivalent files have no
stable identity across revisions?  I might rename the file (changing
its relative path) or edit the file (changing its SHA1-signature).

And isn't it also a consequence of that that logically distinct files
may have no unique identity aside from relative path in revisions
where the relative path has not changed?  I might rename a file to one
location and copy it to another in a single transaction, creating two
files with equal SHA1 signatures but distinct relpaths, neither
relpath being identical to the preceding revision.  Is it then
possible to tell which is then the descendent of the original and
which a new file?

As consequences of this, I don't see how inexact patching or
out-of-band patching can work except in a limited subset of cases.  By
inexact patching, I mean the application of a changeset between two
arbitrary revisions to a third tree.   By out-of-band patching, I mean
the exchange of changesets by means other than through the revision
control system.

It is the thinking of the darcs guy and of one of the subversion guys
that "well, out-of-band patching doesn't matter and for in-band
patching, complete history is always available".  Is that the monotone
presumption as well?  (I happen to think that is an absurd rationale
but it's not worth arguing about, I suspect.)

Finally, the cryptographic features of monotone are presumably
oriented towards leveraging the human value of trust to achieve some
practical effect.  Is there a nice concise summary somewhere of the
the effect that is purportedly achieved and the proofs that the
cryptographic techniques employed achieve that effect?

Combatively, if interpreted pessimally, but collaboratively if not,
-t







reply via email to

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