monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Packets or Packet I/O no longer works?


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Packets or Packet I/O no longer works?
Date: Wed, 18 May 2005 22:51:18 -0700
User-agent: Mutt/1.5.9i

On Thu, May 19, 2005 at 06:19:51AM +0200, address@hidden wrote:
> On 18 Mai, Nathaniel Smith wrote:
> > On Thu, May 12, 2005 at 07:33:01PM +0200, address@hidden wrote:
> >> That would really be nice ... perhaps I should ask Nathaniel if it
> >> could be possible to allow importing-without-discarding of
> >> revisions that lack its parent. Not sure if this is possible or
> >> even desirable, though ...
> > 
> > Don't we at least spit out a warning when we throw out such
> > revisions? If not, that should definitely be considered a bug...
> 
> I have checked right now with 0.19 and the only thing it says was:
> 
>  monotone: read 103 packets
> 
> No any warning was issued!

Oops.  Bug, say I.

> But what do you think by allowing to import incomplete revisions in
> the past? If I import a full packets dump, at least the manifest and
> the files would be there - ready to be checked out. But the revisions
> parent wouldn't be here, so probably not all functions of monotone
> makes sense in such a case. But at least checkout & checkin branching
> and merging from that version could work, couldn't it?

The trick is, how to allow this, without also allowing weird
brokenness.

For instance, say the real revision graph is A -> B -> C, and you
imported A, then missed B, then imported C.  So what you have is A and
C, only.  Well, umm... looks like your branch has two heads -- after
all, from what you can see, neither A nor C is an ancestor of the
other.  Monotone will try to convince you to merge them, which is
really quite broken!  And merging won't work very well anyway, since A
and C have no common ancestor...

So, I sorta doubt we'll ever allow you to import disconnected pieces
of the revision graph; it's just too hard to keep the data consistent
afterwards.  What we _do_ want to do is allow a more limited form of
this, for the other use case you mention, where someone wants to work
on a project, but doesn't want to have to first fetch the entire
history back to the beginning of time.  I'm pretty sure this is
possible, it's just a question of figuring out the details and making
sure that it doesn't have any nasty edge cases like the one described
above...

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco




reply via email to

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