What is the best way to auto-synchronize two computers?

Asked by Zearin

Here's the setup:
 • 1 laptop, my primary computer, which I take with me almost everywhere, and
 • 1 desktop, which I would love to make more use of, but I *really* don't want to manually sync files back and forth between machines
 • Both are Apples running OS X 10.5 (“Leopard”), which I believe is UNIX under-the-hood. I'm not an expert on the command line (Terminal) by any means, so I pretty much just know the basics: how to get around, mv stuff, and how to follow instructions to compile open source stuff.

Here's what I would like to do:
 • Use Bazaar to allow my personal code/programming projects to synchronize between both machines
 • If scripts/hooks or some other magic I'm not aware of could make this happen automatically whenever my laptop hops onto the wireless network at home, that would be great.
 • Otherwise, I'd like to have the everyday aspect of syncing be as minimal as possible (as few commands as possible to sync the code). I'm comfortable executing commands for commits and so on, in order to keep a detailed history of my code.

Here's my dilemma:
 • Although I have been familiar with the *absolute* basics of VCS for a long time, I have never had regular use of one. Bazaar's decentralized nature makes it especially attractive for someone like me to keep a personal revision history.
 • However, although the Bazaar documentation is *excellent* (great work, authors! keep it up!), there is understandably a lot of effort devoted to differentiating Bazaar from other VCS tools. (I know of CVS, but the only other such tool I have dabbled in is Subversion.) Because Bazaar strives to be so flexible and accomodate people used to different workflows, I have a very hard time distinguishing which features are considered the “pure Bazaar way” vs. those that are provided as “convenience / comfort” features for those migrating from other VCS tools.
 • When I look at the tremendous expanse of possible workflows, I am a bit too overwhelmed to choose a setup and feel confident that I am not shortchanging myself on something.
 • The above applies in general to my understanding of Bazaar, but in particular I am fuzzy on working trees. In the centralized model, because the history is in the central repository, checking out a working tree makes sense (because it's necessary). I get the sense that working trees are not really necessary in Bazaar, yet because of familiarity with other tools like Subversion, the concept of working trees keeps being mentioned.

Question #1:
 • Is it really necessary to keep a working tree with Bazaar? Or can you just work directly on the branch, commit changes along the way, and then (in my laptop + desktop scenario) tell my other machine `bzr update` and that's it?

Question #2:
 • I am intrigued by the “smart server” feature. Could this be used in my scenario to provide any benefits over just running plain `bzr`?

Question information

English Edit question
Bazaar Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:
Revision history for this message
Martin Pool (mbp) said :

A1: Yes, you need a working tree, because that's where you edit the files. However, it can coexist with the branch and you don't need to deal with it as a separate object.

A2: Yes, you can use this.

Basciallly what you need to do is just

laptop% bzr init-repo ~/project
laptop% bzr init ~/project/trunk
laptop% cd ~/project/trunk
copy your files in there, then do bzr add and commit to store them, as per the documentation
then to push to the other machine, run
desktop% bzr init-repo ~/project
laptop% bzr push bzr+ssh://desktop/home/me/project/trunk

then next time you're on the desktop, just cd to that directory and run bzr update -- or use pull instead to bring them across

Hope that helps

Revision history for this message
Zearin (zearin) said :

Thanks, this has been very helpful so far!

I do have a few more questions, and I follow-up to one of your answers.

You said, “Yes, you need a working tree, because that's where you edit the files. However, it can coexist with the branch and you don't need to deal with it as a separate object.”

I don't quite follow you…could you rephrase or elaborate on this?

Question #3:
The files I would like to put under version control fall into 3 basic categories:
 (1) reusable code from others' projects;
 (2) reusable code I have written; and
 (3) my projects.

Basically my dir structure is:
• ~/Developer
 ⁃ libs
  ⁃ org.sourceforge
   ⁃ project
   ⁃ project
   ⁃ …
  ⁃ org.tigris
   ⁃ …
 ⁃ mylibs
  ⁃ category
   ⁃ project
   ⁃ project
   ⁃ …
  ⁃ category
   ⁃ …
 ⁃ projects
  ⁃ domain.name
   ⁃ project
   ⁃ project
   ⁃ …
  ⁃ domain.name
   ⁃ …

Since Bazaar recommends a separate repository per project, how should I organize my folders into repositories and branches?
 • one for /lib, one for /mylib, and one for /projects?
 • one for each domain or category beneath the 3 major categories?
 • one per project?
 • something else?

Revision history for this message
Vincent Ladeuil (vila) said :


The working tree is where your the files you edit reside.

There is also a '.bzr' directory at the root of your working tree. You can't see it from the finder. But if you open a terminal and type 'ls -al .bzr' you'll see it contains a bunch of files.

Without going into details, let's call them the bzr control files, they contain the history of your branch in what is called a repository.


By default each branch contains its own repository.

You can share a repository between several branches by doing 'bzr init-repo project' and then all branches created *under* project will use that repository instead of their private one (in fact they will not even have a private one).

Depending on how you work you will then have a layout like:


All these branches will share the same repository.

You *can* share a repository between projects, bzr doesn't impose no restrictions.

You can even change your mind at some point in time and migrate some branches from one repository to the other by doing (pseudo script):

  bzr init-repo /new-repo

  for b in /old-repo/*:
    bzr branch /old-repo/b /new-repo/b

Once all your branches have been migrated you delete the /old-repo hierarchy (check your new branches first :)

How your organize your hierarchy and how many repositories you will create is really a matter of taste and habits.

P.S.: It's better to file new questions so that they stay focused on one subject, people searching answers will find them more easily.

Revision history for this message
Zearin (zearin) said :

Thanks vila. I'll ask my new questions in new threads. :)