Re: [Monotone-devel] broken UI for mtn commit

[Matthew Sackman]

Just adding my thoughts on this...

In this email, I'm using "head" deliberately in quotes, to refer to
projections of the current state of the workspace (to borrow from
database terminology!).

On Wed, Aug 01, 2007 at 02:25:41PM -0700, Nathaniel Smith wrote:
> What do *you* think should happen with cases involving directory
> renames and drops, rather than just adds?  There's one example in that
> email, here's another:
> 
> $ mtn rename foo/ bar/
> $ mtn mkdir foo
> $ echo 'blah' > foo/blah.txt
> $ mtn add foo/blah.txt
> $ mtn ci foo/blah.txt
> 
> Should this automatically commit the rename of old-foo/ to bar/?

Yes, it's a straightforward dependency. A ci seems to typically indicate
the "head" change to be committed. If there is a partial-ordering or DAG
of events that lead to this head then that is implicitly required to be
committed too.

However, I would need to think long and hard as to whether, if it's a
DAG or a partial ordering, what on earth do you do if there are multiple
possible paths to the "head" event. Maybe you just have to commit every
event that is included on any path that leads from the pristine revision
to the indicated head.

> Here's another:
> 
> $ mtn drop bar/
> $ mtn rename foo/ bar/
> $ mtn mkdir foo
> $ echo 'blah' > foo/blah.txt
> $ mtn ci foo/blah.txt
> 
> Should this automatically commit the deletion of old-bar/, and the
> rename of old-foo/ to bar/?

ci foo/blah.txt depends on ci foo depends on mkdir foo depends on rename
foo bar depends on drop bar. Yes, I think that follows the chain up
without issue. The jump seems to me to be the depenedency between mkdir
foo and rename foo bar. But I guess that it's not hard as in order to
mtn add foo, as would be required, the old foo has to be out of the way,
thus requiring the rename foo bar.

> Here's another:
> 
> $ mtn rename foo/ bar/
> $ echo 'blah' > bar/blah.txt
> $ mtn add bar/blah.txt
> $ mtn ci bar/blah.txt
> 
> Should this automatically commit the rename of foo/ to bar/?

Yes, I would argue that that is specified by the fact that it's mtn ci
bar/blah.txt and not mtn ci foo/blah.txt - i.e. the rename is implied by
the fact that the indicated "head" is obviously post the rename.

Just taking your example from the mail you cited:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/7689/focus=7701

> Regarding the idea of automatically including dependencies, what do
> you think about the case:
> $ mtn drop bar
> $ mtn rename foo bar
> $ mtn commit foo
> Should monotone automatically commit the deletion of "bar"?  It can't
> commit the rename otherwise.

I would say therein lies the answer. But in this case, the ci is invalid
as foo no longer exists. mtn ci bar would definately commit the rename
and the drop. To be clear, the mtn ci would have to indicate a valid
current "head", not just any node from pristine revision to the current
state.

> I'm not throwing these question at you to say what you want is too
> hard, maybe there are good answers to all of them.  But we physically
> can't add support for automatically expanding restrictions to include
> other random things without having *some* answer to these questions.

So, the question is, can you have divergence? Having thought about it
for 30 seconds, I think you'd always have a total order and so it should
be fine - how can there be more than one sequence of actions that could
lead from the pristine revision to the current indicated "head" ?

Given that we're basically talking about the state of filesystems which
normally misbehave unless events are totally ordered, I can't see why
this would go wrong. Maybe a night's sleep will reveal answers to me!

Anyway, a few more examples:

$ mkdir foo
$ mkdir foo/bar
$ mkdir foo/baz
$ touch foo/bar/wibble.txt

$ mtn ci foo/baz  # no, nothing happens, we're not doing inference

$ mtn add foo/baz # adds can cause other adds, so add foo and foo/baz
$ mtn ci          # fine, no problem

$ mtn drop foo/baz # err on the side of safety, even if foo isn't
                   # required anymore, probably shouldn't remove it,
                   # but that breaks symmetry i.e.
                   # $ mkdir -p a/b
                   # $ mtn add a/b
                   # $ mtn drop a/b
                   # $ mtn ci # would still ci a

$ mtn ci foo/bar/wibble.txt  # no, no inference, must be manually added
$ mtn add foo/bar/wibble.txt # adds in foo/bar too
$ mtn ci foo/bar/wibble.txt

Ahh, here it is, and no sleep required. To drop or not to drop? - that is
the question. The "head" does not require it, but it has been explicitly
recorded in the _MTN/revision file. You can get from the most revision
to the addition of bar and bar/wibble.txt without the drop.

mtn ci on its own simply does what's recorded in the revision file.
mtn ci does not do inference, if it did inference then you wouldn't have
to manually add files. So therefore, the safe thing to do is to err on
the side of caution and to find the shortest path from the previous
revision to the indicated "head".

Thus I would say the drop should not be ci'd in this case.

Matthew
-- 
Matthew Sackman
http://www.wellquite.org/