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

[Tom Tromey]

graydon> correct. identity of files is imo pretty transient. it's contents
graydon> which interest me, not which inode the file was in. I don't track any
graydon> sort of unique identifier for "a file over its lifetime".

.. But if you have the requisite history in your database, monotone
will know (once renames are implemented) about this sort of identity.
This in turn ought to make cross-branch merging more reliable in the
face of renames.  (Unless I misunderstand the merge process, which I
suspect I do.)

I've read that subversion has support for not only renames, but also
copies.  I'm not sure what the use case is here.  When do copies
really happen?

Tom> I might rename a file to one location and copy it to another in a
Tom> single transaction, creating two files with equal SHA1 signatures
Tom> but distinct relpaths, neither relpath being identical to the
Tom> preceding revision.  Is it then possible to tell which is then the
Tom> descendent of the original and which a new file?

Aren't they both descendants of the original?

I guess there is a weird corner case here.  If you base information
about copies from SHA1 signatures, then any new empty file will appear
to be related to some pre-existing empty file.  To me this seems like
a UI problem; but then I'm not averse to requiring "monotone copy" or
"monotone rename".

graydon> you should note, however, that file ancestry information -- history in
graydon> general -- is never assured to be *complete* in monotone, just
graydon> self-identifying. you can have 'less than all' of history, and things
graydon> will carry on working, so long as you have full head versions. deltas
graydon> are stored backwards, and intermediate versions can be aggregated or
graydon> deleted.

I've been wondering about this a bit.  First, what the UI will look
like?  Second, it seems to me that it might be conceptually to
un-aggregate intermediate versions.  E.g., insert a note after the
fact indicating that some add+delete is really a rename, to make some
set of patches apply more easily.

Tom> As consequences of this, I don't see how inexact patching or
Tom> out-of-band patching can work except in a limited subset of cases.  By
Tom> inexact patching, I mean the application of a changeset between two
Tom> arbitrary revisions to a third tree.

For inexact patching, do you have some specific set of cases in mind?
I would expect that the typical developer will have a fairly complete
set of history (at least back to the branch points of the branches he
is interested in).

Tom> By out-of-band patching, I mean the exchange of changesets by
Tom> means other than through the revision control system.

When working on gcj, I tend to see two kinds of patches on the patch
list.  One is a patch from a known contributor.  Usually these are
made with cvs, and they go through the patch list for review and
approval.  Sometimes the regular contributor doesn't have cvs write
access, so a maintainer must also commit.

I would expect all these users to use monotone.  They will just commit
to their local repositories and send out the packets.  A maintainer
will review the change (we'll have some tool to display the packets as
a unidiff).  Approval is simply re-signing it; anybody incorporating
patches from the patch list into their database need do nothing
special.  (This is sort of a dream for me, where the act of approving
a patch is identical to committing it, requiring no extra action on my
part...)

The other sort of patch I usually see is a patch against some gcj
release.  This patch typically comes from somebody who isn't
ordinarily involved in gcj work.

monotone's fork model looks nice here.  For instance, if random user
sends in a patch against the latest release, you can easily apply his
patch to that release and check it in, creating a new merge
obligation.  You don't need to worry about applying the patch to the
current head revision; that will be handled at merge time.

graydon> the first reason is obvious: you don't need to trust anyone during
graydon> communication because you can evaluate the trustworthyness of what was
graydon> said after the fact, and re-evaluate it if your opinion of the speaker
graydon> changes. so there's no communication protocol, nor any expression of
graydon> trust during communication. you speak and listen promiscuously, taking
graydon> packets any soruce that can provide them, but act conservatively based
graydon> on evaluation of signatures.

I've been wondering about this a bit lately.

For instance, when working on the "MT/options" patch, I considered
making a new "tromey+experimental" key, and committing my working
change using that.  Then once we're happy with it, I would re-sign it
with my real key.

But I'm not sure this approach would work very well.  I don't think
you can look at these revisions without trusting that key.  And there
doesn't seem to be a way to temporarily trust a key, or have different
levels of trust for different working copies.

I think there's a few things like this that have yet to be worked out
in practice.  I suppose it might be a bit easier had I set up my own
depot; then I might be less cautious about making temporary branches
and generally experimenting more.  I see this sort of thing as a
promising feature of monotone, but one that I haven't really explored
yet.

graydon> the second reason, more subtle, is to enable "monotonic update". when
graydon> you get packets from some other monotone user, you incorporate them
graydon> into your database, but you do not necessarily use them.

Another thing we should think about is establishing some conventions
for naming these certificates.  A "here's what we do" guide would be
pretty helpful to new users of monotone.

Also, I'd be interested in having us start signing monotone itself
based on build/test status.

Tom