Hi Mary, I was drawn to Bazaar for the same reason as you :) The approach that I have taken is as suggested by Ian Clatworthy on 27 March 2008: <a href="https://lists.ubuntu.com/archives/bazaar/2008q1/039687.html">https://lists.ubuntu.com/archives/bazaar/2008q1/039687.html</a> Basically: 1. Initialise a shared repository on each of your machines. 2. Checkout your master copy into each shared repository. 3. Branch from each checkout into a working branch. Work using the working branch (duh). You can make commits quite freely. When you are done with a piece of work, merge the working branch into the checkout and commit. If you suddenly need to leave before completing a piece of work, you can always update your checkout without worrying about your working branch. If you happen to want to do another piece of work before the one you are working on is done, just make another working branch (i.e., a "feature branch", and I believe some people recommend just having lots of feature branches corresponding to each piece of work). Regards, Eugene <div class="gmail_quote">On Fri, Dec 12, 2008 at 8:45 AM, Mary Gardiner <<a href="mailto:mary@puzzling.org">mary@puzzling.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> My primary use of Bazaar is for my PhD project, of which I keep copies for various reasons (usually available CPU power) on five different machines: my laptop, my work desktop and three servers. I have used checkouts to date, for these reasons:  - my model roughly corresponds to the idea of there being a master copy   from which the various copies more or less derive  - bzr update, resolve conflicts, bzr commit should in theory involve   less network round-trips than pull, oops that failed, merge, resolve   conflicts, push and network round-trips are to be minimised when I am   in "help 10 minutes to the train, better make sure I have the latest   code so I can work offline" mode  - the pull, fail, merge, push mechanism causes criss-cross merges quite   quickly However, I do quite a lot of work and commits either offline (on trains usually) or on two machines simultaneously (one for writing English, one for writing code) so I do tend to give the offline commits a workout. There are very long-standing bugs with conflicts and offline commits in checkouts, particularly:  - adding a directory in a local commit is regarded as an inherent   conflict if you happen to have any unversioned files in the new   directory at the time of update (eg, .pyc files), bug 120970  - if I forget to do a --local commit before updating, difficult   conflicts can ensue: bugs 113809 and 236724. I hit these bugs about twice a week, and it's been known to take me an hour or so to recall how to dig myself out of them without needing to delete and re-add files to the repository. (113809 is pretty reliably bewildering when it occurs as the behaviour I described in 228506.) So, do others use checkouts for these kind of single-person projects? Do you do local commits? If so, how do you work around the above bugs? If not, what are you doing instead? -Mary </blockquote></div>