monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Annoying behaviour with merge_into_dir


From: Bruce Stephens
Subject: [Monotone-devel] Annoying behaviour with merge_into_dir
Date: Thu, 15 Feb 2007 17:47:03 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux)

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:

    format_version "1"

    new_manifest [b35bbc2194c1b9930bcdda83a89102e171b6e255]

    old_revision [3a2dd050b28c901aa41d21d4e29ccd163de916a4]

    rename ""
        to "db"

    add_dir ""

    add_file "another"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

    add_file "main"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

    old_revision [44b9433e24026b46d818d5df0c941a40e9d36052]

    add_dir "db"

    add_file "db/db_file"
     content [f1d2d2f924e986ac86fdf7b36c94bcdf32beec15]

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?

Ah, if I change "all" directly (rather than "main"), then that behaves
as I'd expect: I get just the change.

If I change "db", adding a file change_db, I get:

    format_version "1"

    new_manifest [ca22aef916f537b9a997a34ca70e4ce4483a643a]

    old_revision [2fe07b5a9506d9a0b2bf7a854ac9b7ab13a95320]

    add_file "db/change_db"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

    old_revision [dabbd2751de0b7102d5dd9356560fc75c25a8e77]

    rename ""
        to "db"

    add_dir ""

    add_file "another"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

    add_file "change"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

    add_file "change_all"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

    add_file "main"
     content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

So again, this is *much* more than I'd like.  The revision 2fe0
already contains "another", "change", etc., and the "db" directory has
already been renamed by then.

For a few files this isn't significant, but I've got about a dozen
branches, several with hundreds of files, and I'm getting the same set
of

    add_dir "boost"

    add_dir "boost/include"

    add_dir "boost/include/boost"

    add_dir "boost/include/boost/boost"

    [many lines deleted]

for every revision.

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)?




reply via email to

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