Recommended use of Bazaar for single-committer multiple-machine projects?

[Eugene Wee]

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:
https://lists.ubuntu.com/archives/bazaar/2008q1/039687.html

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

On Fri, Dec 12, 2008 at 8:45 AM, Mary Gardiner <mary at puzzling.org> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20081212/cd8b43e0/attachment.htm