Bazaar-NG traffic #2

[James Blackwell]

Welcome to Bazaar-NG traffic #2 sneak preview. This covers the Bazaar-NG
mailing list from 28 September to 3 October, with minor overlap in both
directions. This traffic will be posted on the wiki at
http://bazaar.canonical.com wiki after a day or two to allow time for
corrections. 

= Kinks in the Executable bit =

Bazaar-NG now supports executable bits. One can infer that this is the work
by Gustavo Niemeyer last week. This patch seems to work pretty good on the
whole. The last few days, however, have seen a large flurry of emails
flying back and forth about small bugs in the code and how to properly
store data for "bzr revert"

= _Always_ Unicode =

The Unicode discussions continued this week. Last week, Alexander Belchenko
referred to some bzr code that didn't handle Russian filenames properly.
This week Belchenko followed up a couple more times without a response. 

= Bazaar-NG Export =

Last week Wouter Bolsterlee wrote a patch to fix a bug in in bzr export
that created directories that ended in ".tar" (as in
"myproject-snapshot-revno-NNN.tar/"). Bolsterlee supplied a patch via the
list. This week, Aaron Bentley followed up with some suggestions on how to
improve the patch.

In another thread Mark Rosenstand asked Chris McCormick how he wished to
receive bug reports on bzr export. He asked that bug reports be sent to the
bazaar-NG list for now with a carbon to him, with a plan to move to a
separate list if bzr-traffic got too busy.

= How to do tabs in bzr =

The thread from last week on how to do threads in bzr wrapped up this week.
John Meinel said that some day Jordan Breeding will be able to use named
revisions to supplant the tag capabilities in other RCSs. Meinel then went
on to list several of the questions that still needed answering. Breeding
followed up with a description of how tags worked in mercurial.

= Terminating with a broken pipe =

In a related sub-thread, Martin Pool followed up on a post about bzr
complaining about broken pipes when output was fed through programs like
less. Pool seemed open about whether not to complain about the broken pipe
and started discussing the issue with David Allouche. They both have
decided to get rid of broken pipes and are lightly discussing the matter
for the approach.

= Pull --basis =

At the end of last week John Meinel was involved in a discussion about what
to do with the new pull --basis (which allows one to use another local
branch as a cache for the branch you're getting). Apparently the issue gets
a little more complicated now that weave has been merged into Bazaar-NG.
Robert Collins reports that Pool is already half-way to solving the problem.

In a related discussion off-list, yours truly learned that --basis is
currently disabled for the 0.10pre series at least. 

= Bazaar-NG merge can fail =

Bazaar-NG has a bug in merge when one merges a deletion in which the
contents of the deleted file differ. This problem seems to be related to a
similar problem with deleted directories. After some minor discussion
Aaron Bentley fixed up the deleted file problem. Bentley was looking for a
general solution to solve this whole class of problem, eventually saying "I
just want a plan for how to handle conflicts.  If we had one, I'd probably
have implemented it by now.". A day later, Pool replied to Bentley with a
specification for how to handle a specification that looked more like a
series of rules. Bentley seemed happy with this, asked for information on
some parts and got to work on other parts.

= Bzr-Traffic =

Bentley followed up on the Bzr traffic list with a correction for pull
--basis (pull --basis doesn't perform a pull with pruned history; rather,
it does a pull using a local related branch as an impromptu cache).

Additionally, several people asked for a linking of subjects to posts.
Yours truly replied that he was concerned that the summaries were too
brief to point out posts. This was followed up by Wouter, who suggested
looking at the debian-news mailing list.

"Humans make mistakes, and I'm more human than most". In order to deal with
inaccuracies which will inevitably crop up from time to time, I'll place a
copy of the traffic up on the bazaar-NG wiki a few days after the mailing
list post each week. Modifications and addendum will be marked in bold. :)


= Bzr Segfault = 

Jordan Breeding reported a segfault with Bzr clone, which was rather
surprising as Bazaar-NG is written in python. Pool promptly replied that
he should never see that behavior. Pool apparently suspects the
installation on Breeding's machine.

= Star or Parallel Merge =

This thread started off slow, but made up for lost time. William Dode asked
for more documentation and was later pointed to some Bazaar-NG
documentation. This then spawned off a large thread involving Bentley,
Allouche, Meinel, Pool, yours truly and Jan Hudec. This thread, which is
still active, was the combination of two discussions.

The first discussion covered whether or not bzr log should include listings
of third party merges; i.e. If Sally merges Sam and Beth and then Chris
Merges Sally, should he see Sam and Beth's logs by default when he runs
"bzr log". No solid conclusion was arrived at, though the general
consensus seems to be to not show those third party merges.

The other conversation, which is still ongoing, ended up being a discussion
about determining merge ancestors and flaws in tla/bazaar's star-merge. 

= Switching to Weave! =

Pool announced that active development would move over to the branch with
the new weave format. Though the announcement was a little late
(development had moved ad hoc a couple weeks prior). Nobody argued, yours
truly updated the documentation. :) 

= BzrTools 0.0.9 released =

Bentley announced the release of bzrtools 0.0.9, which is versionlocked
with Bazaar-NG

= The New-NewFormat? =

Collins introduced a change to the newformat storage format. Collins asked
if anybody was using newformat for any actual data (which would necessitate
tools to perform conversion).

Apparently not, as the only direct question was about support for
executable bits from Bentley. Everyone else dived into a long discussion
about the storage format. The two camps were basically XML (current) and
RFC-822 with a splinter not-quite RFC-822 group. The battle waged back and
forth with Neimeyer eventually providing a proof of concept and Pool
admitting he had squirreled something like it away before. Pool seems to be
considering a test between XML and RFC822 storage mechanisms.

Weave is line based, so the end battle in this will probably be a race
between a XML that's written to be parsed well in line based format versus
RFC-822.

= Code Cleanup =

Niemeyer called for the code in Bzr to get cleaned up. Variable names are
not currently fully consistent (a nightmare for something written in
python). He wrapped up with a call to write coding conventions for
Bazaar-NG. Martin, Meinel and Pool liked the idea and jumped in.
Eventually, Pool made a HACKING file which was put up on the wiki and in
the source code.

This thread then spawned the next thread.

= Code Documentation = 

In this one, Allouche and Belchenko discussed how to document the code in
place in a way that could be easily retrieved and formatted. The consensus
was to use Epydoc in ReSt format.

= Compressing Weave Revisions =

Bentley noticed that the revision storage for a branch is often larger than
the tree storage itself (Note: For Bazaar-NG with newformat, the ratio is
down to 7:1, which is much better than the 29:1 for oldformat and much
worse than 2.5:1 for mercurial).

This led to a discussion between Bentley, Meinel, Niemeyer and Pool in
which they measured the sizes of revision data and started seriously
considering which parts of the revision storage could be stored differently
and/or compressed.

= Merge revision reporting confusing =

Another user, this time Tommi Komulaine, reported that merge was a little
confusing about what merges had or hadn't merged. Bentley pointed Komulaine
at the star-merge thread for a discussion of the problem.

= Postprocessing of Commit messages =

Belchenko supplied a patch to trim extra newlines at the end of commit
messages written by an editor. Pool asked for community input on the
approval, which was favorable. This will probably be merged.

= Where for art thou, $EDITOR? =

The $EDITOR thread continued this week. Several people went back on forth
with this, without any real progress.

= Caching remote operations =

A recurring thread (started this time by Belchenko) is that getting
branches is painfully slow -- especially on dialup connections. In
Belchenko's case he had a partially retrieved tree because of a short lived
dial up connection.  Bentley suggested that he try out the fetch-missing
script from bzrtools, which will pull missing code into a branch.

After a short thread discussing what Belchenko actually meant by a cache
the thread moved into a comparison between getting branches via "bzr get"
and rsync. The result of this conversation was the same as previous ones:
   bzr get > rsync > bzr pull

= New code for inventory =

Collins requested a merge for per kind classes to the inventory system,
which Pool reported was dependent upon a class that had presumably been
removed. 

= Test case for merge =

Bentley supplied a test case for a merge that works with diff3 but fails
with Merge3. 

= New svn2bzr tool = 

Neimeyer announced the first release of svn2bzr this week. Check it out at
http://bazaar.canonical.com/svn2bzr. A couple users asked after the sorts
of capabilities that svn2bzr that tailor didn't have. Neimeyer's answer was
that he was unable to determine whether tailor could create real bzr
branches.

= Xtla moving to Bazaar-NG? = 

Matthieu Moy, known for his work on Arch and Bazaar 1.X started showing
interest in providing Bzr support in Xtla. This opened up a bit of a thread
about whether or not to use Pymacs to ease the support.

= Weave slow on 450Mhz celeron =

Meinel reported that weave was very slow on his 450 mhz Celeron. Several
other people replied that weave was indeed running much slower than
expected. Pool replied that some slowdown was expected because of
compression, but this level of performance wasn't expected. Collins then
suggested that this would be a great smallish task for someone to jump in
on.

= Decentralized, not Distributed =

Meinel reported that the wording on the wiki describing Bazaar-NG wasn't
quite in sync with the proper behavior. Though everyone seemed satisfied
that the new description was better, many felt that the description still
wasn't quite right -- though nobody could come up with a better
description. One point of note: everyone that expressed an opinion agreed
that "decentralized revision control" was a much better term than
"distributed revision control"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051011/8a7cfe52/attachment.pgp