Commit direct to other repositories [then pull]

[Greg Ward]

On Sun, Feb 21, 2010 at 6:57 PM, James Sleeman <mercurial at gogo.co.nz> wrote:
> Situation:
>   I'm a web developer, I have a core (trunk) of a framework
>   I have clients (branches of trunk), who have sites (branches of client),
>   I do development mainly in the site branches and "propagate" the changes
> up and down client & site
>
> I'm presently using Subversion with a structure like this...
>
>  /trunk
>  /branches/client/client-1
>  /branches/site/site-A
>
> client-1 is branch of trunk
> site-A is branch of client-1
>
[...]
> The first inclination as to handle the above is to have clients be a clone
> of trunk, sites be a clone of client.

Or you could used named branches.  The big advantage of named branches
is that everything is right there in one repository, so you don't have
to jump around between different clones to see the big picture.  And
since the branch name is burned into the changeset, you will always
know that changeset X happened on branch Y (site-foo, client-bar,
whatever).  The catch is that named branches are forever.  If you're
going to have tens of these branches over many years, no big deal.  If
you're going to have thousands, then named branches are probably not
the answer.

> But how to stop "site only" changes getting into client and "client only"
> changes getting into trunk while still allowing most/all development
> directly in site and then getting the certain changes cleanly "up the line"?
>  This is important.

The usual trick is a dummy merge.  Imagine you go with named branches
(easier to illustrate):

  hg branch client-ABC       # new branch for new client
  [...commit happily away...]

Now you have changes on client-ABC that are general purpose and belong
on the trunk.  No problem:

  hg update default
  hg merge client-ABC
  hg commit -m"merge from client-ABC"

But what if those changes on client-ABC are client-specific and should
not get to the trunk?  Again, not hard:

  hg update default
  hg debugsetparents . client-ABC
  hg commit -m"dummy merge with client-ABC to prevent stuff from
polluting the trunk"

(debugsetparents is a powerful and slightly mysterious command.  Be
sure you understand what "parents of the working directory" means
before you use this irrevocably.  ;-)

(Also, the procedure usually advertised for dummy merge is this:

  HGMERGE=internal:local hg merge client-ABC
  hg revert --all
  hg commit -m"dummy merge with client-ABC to prevent stuff from
polluting the trunk"

but I honestly don't understand why people use that when
debugsetparents is equivalent.)

Finally, if client-ABC contains a mix of general-purpose and
client-specific changes, you'll have to do a couple of merges.  Will
make life easier if you avoid alternating too much between the two
types: do a string of general changes, then a string of
client-specific changes.  That way you only have to do two merges: one
"real" and one "dummy".

Greg