How can I have two “streams of development” (branches?) track each other while remaining different in particular ways?

Question

BRIEF:

I want to have two (or more) "streams of development" / environments track each other, sending changes between each other in both directions, without converging totally - while preserving certain key, essential, differences?

DETAIL, ONE PARTICULAR EXAMPLE:

Here is one particular example:

I have been version controlling my home directory, glew-home, for, oh, 28 years. RCS, SCCS, many RCS wrappers, CVS, SVN, a brief period of experimentation with early DVCS like Monotone and Darcs, bzr, git, and now Mercurial. At the moment I am mainly happy using Mercurial, although I'll jump back to git or bzr as needed.

Now, my home directory is similar, but not identical, on many systems. The biggest differences are between Cygwin and the various Linuxes at work. I try to make them as smilar as possible, but the differences arise, and often need to persist.

Here is a trivial example of the differences: on Cygwin, on my personally owned laptop, ~/LOG is a symlink to ~/LOG.dir/LOG.cygwin.glew-home, while at work ~/LOG is a symlink to something like ~/work/LOG.dir/LOG.work.

Reason: anything proprietary needs to stay at work. ~/work is a separate repository, ~/work/.hg, and is NOT pushed/pulled or otherwise synchronized with my personal computer(s).

Problem: I want to keep these symlinks (and several other files) different. But I want to synchronize all other files. I make changes to my environment in both places. If I make a change to my ~/.emacs at work I want to send it home, and vice versa.

Q: how can I most conveniently do this?

In the bad old days I would use a common repository, say a common CVS repo. CVS doesn't handle symlinks, but say that I had a script that generated symlinks from a template stored in CVS. I would arrange for the symlink template for ~/LOG to have different branches for my cygwin-laptop and for work. I would create workspaces with most files pointing to the same branch of their corresponding RCS/CVS repos, while the files that differed between cygwin-linux and work would have their corresponding branches checked out into their corresponding workspaces.

This worked, although it was a bit of a pain to maintain.

I have not figured out a good way to do this with a modern DVCS, like Mercurial (or Got, or Bzr).

These modern DVCS tools do whole-repo branching, not per-file branching. They do not understand the notion of two branches that are identical for most files, but which differ in only certain files.

When I try to track two branches, I always end up with the essential differences being propagated.

Some have suggested Makefiles. Not attractive.

I have considered making the essential changes base revs, and constantly rebasing. But I don't like rebasing that much.

Better ideas appreciated.

Quilt?

Answer 1

In git you could maintain a master branch with all the common files (maybe plus the differing ones in some default state) and customized branches like work or cygwin.

When you want to make a change that should propagate to every machine you do it in master. If you want something to go only to work/cygwin machines, you do it in an appropriate branch.

When you pull new changes from master on a machine that has a customized branch checked out, you simply have to git merge master or git rebase master from that branch.

Which one you should use is a matter of preference, the resulting working directory is the same, only the history differs. Using merge you will always see when you updated the customized branch with changes from master. Using rebase it will look like all the customizations branch off the tip of master, as if you had first done everything in master and only then committed any customizations.

Unfortunately I have no idea about other DVCS's as I don't have any experience with them, however, I believe that this procedure for git is pretty straightforward.