monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Annoying behaviour with merge_into_dir


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Annoying behaviour with merge_into_dir
Date: Thu, 15 Feb 2007 12:24:41 -0600

On Thu, 2007-02-15 at 17:47 +0000, Bruce Stephens wrote:
> merge_into_dir is described as a possible alternative to nested
> checkouts, so I decided to try it.
> 
> As an example, suppose I currently have a branch "main", and I want to
> merge in a branch "db" into a the directory "db".  Rather than
> complicating "main" itself, I'll branch that first, to "all".
> 
> So now I do "mtn merge_into_dir db all db", and that works OK.  A
> checkout looks fine, and automate_get_revision shows:
[...]
> Now I change "main", and propagate the change to "all".  ("main" is
> where most of the work happens.)
> 
> Updating "all" works fine.
> 
> But get_revision is disappointing:
> 
>     format_version "1"
> 
>     new_manifest [c3e572809bffd0011e4b8d061baed9ce7f06b36f]
> 
>     old_revision [4259cbe62814990e1c3b0fbec8ed99c32da1cdea]
> 
>     add_file "change"
>      content [da39a3ee5e6b4b0d3255bfef95601890afd80709]
> 
>     old_revision [b89448d98d849e7e77aa21bc5b682bd5e51f3ad7]
> 
>     add_dir "db"
> 
>     add_file "another"
>      content [da39a3ee5e6b4b0d3255bfef95601890afd80709]
> 
>     add_file "db/db_file"
>      content [f1d2d2f924e986ac86fdf7b36c94bcdf32beec15]
> 
> It's mentioning both the old revisions, so why is it adding all these
> things again?  The only thing that's changed is the new file "change",
> surely?

It has two parents. Compared to one of the parents (the one in "all"),
the only change is the addition of "change". Compared to the other
parent (the one in "main"), there are additions of everything else that
has been merged into "all".

> Is this how it's supposed to be?  Is this how it must be, because it
> makes this way of working infeasible, I think (at least for me)?

Yes, this is how it's supposed to be.

In most cases (whenever the parents have a common ancestor), the two
halves of a merge revision are redundant. Only storing one half could
save some space, but would make some operations slower. I don't think
anyone has seen a need to look into whether this is a sensible thing to
do yet... do you know what percentage of space this could actually save
you? You can get an upper bound from 'db info' and the "revisions" and
"total" byte counts (this gives that revisions are 12% of total for a db
of off.net/'*').

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net





reply via email to

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