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

[Patrick Georgi]

Am Sun, 04 May 2008 17:37:41 +0100
schrieb Bruce Stephens <address@hidden>:

> Patrick Georgi <address@hidden> writes:
> 
> [...]
> 
> >> I'd have thought note_netsync_revision_received or something would
> >> be OK for that?  Maybe one wants a hook that receives all the
> >> revisions in one go or something?
> > hmm.. initialize a branch list at the beginning, then check each
> > incoming revision - could work.. thanks, I didn't think of the
> > hooks!
> 
> Maybe the existing hooks are sufficient, actually.  Or do hooks get
> evaluated in different lua interpreters?  If they're evaluated in the
> same one, then you could presumably code up something using
> note_netsync_start, etc.?
that's the idea. extra/display_branches.lua (thanks Richard Levitte for
it, and Stephen Leake for the hint) does half of it: displaying all
affected branches.
Adding a way to denote new branches shouldn't be too hard.

> So mostly you use rebase on local work---you commit when it makes
> sense, and then reorganise the changes.  Perhaps to improve the
> reviewability of the changes, or in response to review, or maybe just
> to incorporate upstream changes (you can merge, of course, but
> sometimes it makes just as much sense to linearise the changes by
> moving your changes to the current head).
Basically mtn-plucking a set of revisions to somewhere else, while
giving the head of "somewhere else" a suspend cert. That will make the
repository grow a lot, of course (as we don't throw away things)...

If someone else already worked from the old head, things will be messy:
two heads with "unrelated" changes (esp. for new files and the like!).

I'm just trying to wrap my head around how such things could be
approached.

> > Which is why I still think that rewriting history is a bad idea.
> Perhaps.  I'd just comment that git users seem to find it works fine
> and is valuable.  I think perhaps you're imagining it gets used in
> problematic situations where it (mostly) doesn't.
We thought that would be the case for certain currently problematic
non-content merge scenarios, too...
Together with that "heads-on-server" tracking (for looking for
local updates) and the validation if you're working on uncommitted
revisions (which could then even be kill_rev_locally'd), that sounds
possible and reasonably safe.

> > For monotone it would be more like "reapply (from, to) to (new base
> > rev)".  That isn't _too_ different from just merging.. (just that
> > you have one new revision at the top, instead of 250 revs. copied to
> > a new location in the DAG)
> 
> Maybe, though that would only be one part of what "rebase" is used
> for.
The other(s) being?


Regards,
Patrick