Re: [Monotone-devel] Pushing a new project to the depot

[graydon hoare]

Kevin Smith <address@hidden> writes:

> Ah. So I can't force it to queue an exact copy of your tree to my
> depot. I have to make at least one small change, and then it will
> automatically post the whole tree? It makes sense after hearing it,
> but it's not what I expected. I wanted to push an exact copy so I
> could test my depot. No biggie, though.

yeah. I guess we could add another queue sub-command which queues
just what it sees in your working copy (or one of your heads).. just 
haven't added such a command. 

> So if I plan to work on monotone itself, you think it would be better
> for me not to include your historical deltas?

yup. you already have them all in your db (anyone tracking my depot
does) and I already have them in my depot. I figure a dozen copies of
the project history is enough redundancy.

> If someone pulls a copy of monotone from my depot, they would only
> get the change history newer than now.

well, they'll get:

  - all the full base versions you posted with the first commit
  - any deltas since then

if their storage system already has a way to construct the base
versions -- say they've *also* been tracking my depot -- their storage
layer will ignore the new "full versions" when it fetches them. if
their storage system *doesn't* have a way to build those versions,
it'll insert them.

the intention is:

  - someone can track just your depot, or just mine, and get "real
    working trees"

  - someone can track yours *and* mine simultaneously, and not get too
    much duplication

> As I pull updates from your depot into my database, will they be
> posted to my depot individually, or as a bundle somehow?

we used to bundle them, but this caused some subtle problems when
merging histories across depots, so we decided to switch to reposting
them individually. now the history fragment is reposted verbatim,
exactly as you fetched it.

now, if you *want* to aggregate changes -- say you're fetching from a
dozen contributors, but you want to post "big" aggregate changes -- we
recommend the following (which, yes, will eventually be in the docs):

  - make a "contrib" branch and a "publish" branch
  - tell your contributors to commit to the contrib branch
  - each now and then, do "monotone propagate contrib publish"

this will do a nice organized 3-way merge between the last "big"
version on your publish branch and the current head of your contrib
branch, synthesize a single "big" edge between the old publish head
and the merge results, and queue the big edge for posting to a depot
associated with the publish branch.

this organization should scale pretty well, in a sort of tree of
publish / contrib branches, each feeding a higher level of your
organization. that's the plan, anyways.

> The whole reason I'm looking at monotone is for distributed
> development, so I really want to understand this. It's a whole new
> paradigm for me, and I have not worked on a distributed CVS project,
> so I have a lot to learn.

yeah, there's some stuff to learn, and some things we're still
hammering out the details of. please keep asking questions and
pointing out things which don't make sense; it helps me know what to
cover in the docs, and what is currently broken by design.

-graydon