unicode & more

[John A Meinel]

Jeff Rose wrote:
> Hello everyone,
>   I'm just starting a linux port of a small OSX app my roommates wrote,
> and we wanted to use bazaar-ng so we can get familiar and eventually
> help out.  Anyway, on the very first commit after initializing a new
> tree it crashed with this unicode handling exception:
> 
> --------------------
> $bzr ci
> 
> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode  
> byte 0xc3 in position 1: ordinal not in range(128)
>    at /opt/src/bzr.dev/bzrlib/config.py line 463
>    in _auto_user_id
> ----------------------
> 
>   Any ideas?

Try "bzr whoami" to see what name bzr thinks you have. Ultimately,
follow Erik's advice and set your email information. You have a file
which is not in ascii encoding, but python doesn't know what encoding it
is in.

> 
>   Also, I've seen a bit of traffic about how accessing branches over
> http is slower than other mechanisms.  (Although hopefully this is
> speeding up...:-)  What do people recommend we use for now?  Is sftp
> support going to be part of the standard package, or is the standard
> usage model to install all the plugins (kind of like gaim)?

There are a couple reasons why it is slower which are being worked on.
However, as was mentioned elsewhere, http is meant for readonly access.
At some point in the future we will probably end up supporting webdav.
But nobody yet has needed it. Sftp support is a core protocol. We are
planning to have plugins so people can add non-standard protocols (like
rsync or a future webdav). But in general, if a plugin is considered
worthy (has test cases, is shown to be useful for most people), it will
most likely end up in the core.

> 
>   Last, I have a general distributed versioning newbie question.  What's
> the typical workflow for using bazaar in a project with a couple people
> actively developing?  My roommates and I will probably do a bunch of
> hacking while we are away over the holidays, and we'd like to keep in
> sync.  Do we each publish our personal branch and then update with all
> the other branches to stay in sync?  Do we have a central branch that we
> merge with and hope someone else doesn't try to upload while you are
> uploading?  How do people work with this type of setup?  I'm already
> sold on the bazaar model for plenty of reasons, but a little coaching on
> the day-to-day usage would be helpful.  Afterwards I'll be happy to post
> a newbie guide to the wiki...  I've found plenty of discussion of the
> weaknesses of network connected, centralized systems like subversion,
> which I used to use, but it would be nice to have a clear picture of how
> a group of developers working on a project interact with each other
> using bazaar.

The most easily supported workflow is to have everyone have their own
public branch, so they are the only ones committing to it. When I say
public, I just mean that everyone in the group can read it. I don't mean
everyone in the world. (Though obviously opensource projects would work
that way).

One of the branches is considered to be the integration branch. Someone
maintains that branch by merging in the changes from the other branches.
And then other people pull from that branch.

This is loosely a star formation. Bzr supports mesh formation (where
everyone can merge from everyone) so you don't have to be too strict
about it. The star is just because there is an "official" place with
changes that (may) have been reviewed.

How in-sync do you want to stay? It is possible for everyone to use the
same branch at the same time. You have to have a local branch where you
make a commit, and then you 'push' that change to the shared location.
Bzr locks the remote location, so if someone else tries to push while
you are pushing, they should fail. (There is a small issue that local
branches are locked differently than remote branches, so avoid using a
public location as your personal branch)

In general, with this situation, you will want to do:
bzr pull # Get the latest from the shared location
<hack hack hack, make my change>
bzr pull # I'm getting ready to commit, so make sure I'm up-to-date
<resolve any conflicts>
bzr commit -m "Added feature foo"
bzr push # Upload that last commit

If someone sneaks in and pushes inbetween your final pull & push, you
will be out of date, with a commit. At this point, you have 2 options:

bzr merge #Merge in the upstream changes
bzr commit -m "merged changes"
bzr push #Push your branch upstream

The above is because the branches have diverged, and you want to bring
them back into sync. Another possibility is:

bzr uncommit  # Remove my last commit, doesn't change the working tree
bzr pull # Get back up-to-date
<resolve conflicts>
bzr commit -m "Added feature foo"
bzr push

In my integration branch
http://bzr.arbash-meinel.com/branches/bzr/jam-integration
I have added a little bit of code, so that when you set .bzr to group
writable and sticky, all files underneath will also stay group writable,
regardless of umask.

And finally, I implemented bound branches (they commit remotely, before
they commit locally, so you have to stay in sync with your remote
location). But it wasn't the best implementation. I've been rethinking
it, and maybe sometime soon, I'll get it reworked. It is a feature that
I've been wanting.

> 
> Thanks a lot,
> Jeff
> 

Hopefully this has been helpful,
John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051219/a2cb0457/attachment.pgp