Re: [Monotone-devel] Re: OpenEmbedded looking to jump ship

[William Uther]

On 04/05/2008, at 10:37 PM, Patrick Georgi wrote:

> > I feel forced in a work flow:
> >     - git-commit --amend is missing
> > ..
> >     - git-rebase -i is missing
> These two (at least) change history. Monotone has immutable history,
> which is a feature.
> (amend-commit as a shortcut to kill_rev_locally, then commit could  
> work)

While monotone has immutable history, that doesn't stop you from re- 
basing.

re-base is just a way of making another micro-branch, right?  You'll  
then have
two heads locally with the same 'content' in them, but unrelated in  
the monotone
sense so if you tried to merge them you'd get lots of errors.

e.g.  I originally had a base revision X.  I then coded up revs i, j  
and k to get:

  X
  |
  i
  |
  j
  |
  k

But then I decide to re-base and change i,j,k into the cleaner a,b,c:

     X
    / \
   /   \
  i     a
  |     |
  j     b
  |     |
  k     c

If I haven't sent out ijk then I could kill_rev_locally (or suspend)
and there wouldn't be an issue.  If I HAVE sent out of the old revs,
then the ijk revs are "in the wild" and cannot currently be recalled.

You could suspend k.  That would leave c as the sole live head.
Everything is fine until you find that someone already has a local
child of k and when they push it the suspension goes away.

Or you could automatically add a 'merge' revision 'd'.  Rev d would
be the same as rev c, but would also have k as an additional
ancestor:

     X
    / \
   /   \
  i     a
  |     |
  j     b
  |     |
  k     c
   \   /
    \ /
     d

With this setup, if anyone commits a child of k and then tries to
merge, then they'll end up with the merge doing strange things.
Files that existed in X should merge ok.  (They'll do a a three
way merge with k as the ancestor - that should be close enough.)
Files that didn't exist in X will have been introduced separately
in each side of the DAG and how they merge depends upon how d was
generated.  If d deleted the new nodes introduced in ijk then the
new merge will warn about lost data, but will lose changes to those
nodes.

Oooo - fancy option.  If you re-used the node ids of any files
created in ijk when making abc then that would solve any merge
issues.  There would be no deleted node ids.  This could be a
special feature of a 'mtn rebase' command.

The final issues are that when you get the log, you'll get the
log entries for all of ijk and abc.  And that all revs are
permanently out there.  These seem like less important issues.

Just thinking out loud...


(Aside: was the recent problem OE had with suspend because suspend
itself didn't work, or rather because people were using older versions
of monotone that didn't respect suspend certs?)

Be well,

Will        :-}