From: "Pascal J. Bourguignon" pjb@informatimago.com
You can think of a repository as a sequence of patches.
Here and throughout the message you confuse repositories and branches -- branches are sequences of patches, not repositories.
Having different repositories is having different sequences of patches.
When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in.
When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too.
So merging two repositories is more complex than working with only one, in the situations where the patches collide.
Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints).
Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting.
You still can work in different repositories (and, ergo, different branches), just sync the branches often, in both directions, and always work off the latest changes -- this is semantically equivalent to working on a single branch in a centralised repository.
Of course this adds the two-way sync overhead.
regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org