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?

Vizza

The question #2818789 is very similar to the question I posted last night here, in #11790375 // the answers received so far are equally unsatisfactory. // In my post I explain how a more satisfactory solution was available in CVS. I hope that the DVCSes can offer something almost as good. – Vizza

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.

Hartmunn

Yes, this is what I was doing on git, and what I am currently doing on Mercurial (which in this respect works almost the same way as git). It is suboptimal, or at least much more annoying than the CVS equivalent, in that I must always remember to switch to the master branch when making an edit to a shared file, vs. switch or stay on the local branch when making a change to a nonshared file. More precisely, must edit in a workspace on a localized branch, check in any localized file changes, and then switch to the master branch to check in any shared changes. – Vizza

If I make a mistake and edit and checkin a shared file on the local branch, then in Mercurial at least I cannot merge from the local branch to the master, because then I would have to undo any changes to the localized files that do not belong in the master. And if I then merge from the master back to the local branch, that undoing will also propagate. I.e. bidirectional merges do not work so well, at least not in Mercurial. I thought that git had the same problems, but perhaps I was using it wrong. – Vizza

If you make a mistake and edit a file on the localized branch in Mercurial, you could use hg graft to copy the change to the main branch. You could also use the mq extension to take it off the localized branch and put it on the correct branch after you switched. – Smack

Thanks, Steve. Rather than rebasing on top of the patch, history edit to move stuff to the shared or master branch. I'll look at it. – Vizza

By the way, rather than going all the way to a template, I often have ~/.config.system1 and ~/.config.system2, and have a script create a symlink from ~/.config -> ~/.config.system1 as appropriate. // Doesn't help if there are only a few differences, which are replicated, but helps if they are significantly different. // However, I would still prefer to find a solution that handles this better, such as I did in CVS. // Although now that my memory is refreshed, I remember that I often preferred to keep both versions visible in all checkouts, so that universal edits were more like to find them. – Vizza