questions from a new bzr user

[Ramon Diaz-Uriarte]

Oooops, you are right (and, as my wife argues,  my writing stuff late
at night is not a good thing, specially if I am silly enough to place
it on my web page). Actually, this was an internal doc for the people
in my group, but I decided to place it on the web, since its just
simpler.

I'll try to explain, though, and I hope I have not offended anyone.



>
> Line-by-line history of a file
>
>         * hg annotate
>         * darcs annotate
>         * monotone:
> http://lists.gnu.org/archive/html/monotone-devel/2005-04/msg00047.html
>         * svk blame
>         * bzr: not available
>
> 'bzr annotate' has been around for quite some time. And if you install
> the 'gannotate' plugin:
> http://panoramicfeedback.com/opensource/bzr/gannotate/
>
> You can get a really nice graphical annotation. Which puts up the log
> information at the bottom, and colors the lines based on age.

Yes, I actually noticed this the day before yesterday. And I've been
using annotate and gannotate which do in fact work quite nicely.




>
> Add a directory (nicer if recursively)
>
>         * monotone: see 2.6: mtn add
>
> I'm not sure why you are only listing monotone. I'm not sure about the
> others but just plain "bzr add" adds everything underneath the current
> working directory.

Actually, this was a silly thing, since most of them do have that
option. I got alarmed by mercurials issues with directories, and
started to write down how to do it with other systems, but most of
them do, so I stopped.



> Documentation
>
>         * bzr: pss
>
> I'm guessing that 'pss' is not good.


Yes and no. First, I had a harder time finding the documentation it in
a single, unified place, in my first visits to the site.

In addition, when browsing the lists I read issues/terms (e.g., knits)
that I could not locate in the available help. Thus I had (still have)
the feeling that there might be workflows/recommended procedures that
I am not following. I understand some of these are related to newly
available features (knits) but still, it made me feel like the  docs
only scratch the surface of what is really available and that there is
no systematic, comprehensive doc that shows whats in here.


I think that comments similar to these ones have been made several
times in the list.


With regards to the current (2006-05-05, 19:30 local time in Spain)
web page, I'd like to make two comments:

1.  <http://bazaar-vcs.org/Tutorials> takes you to a page where
"IntroToBzr" is listed (and linked to) twice. This can be confussing
(especially, when one needs to open a bunch of tabs to see most of the
documentation).

2. Moreover, "IntroToBzr" is also linked from
<http://bazaar-vcs.org/Documentation>, so the very same document
actually appears three times.

If I may, I'd suggest leaving "IntroToBzr" only in
<http://bazaar-vcs.org/Documentation> and deleting it from the
tutorials page.


>
>
> "Has support from Connectiva Ltd"
>
> That should be Canonical, not Connectiva.
>

OK.

>
> I'm curious what "serious bugs remaining" you believe we have. As far as
> I'm aware, we don't have many serious bugs. More lack of features which
> we wish to have. I suppose there are some performance issues, but a
> whole lot of them will be addressed by the 0.8 release in a short while
> (< 2 weeks).
>

I visited the bugs tracking page several times in late April and the
first two days of May, and saw several that were marked either
critical or major, and that had been confirmed.
(This is not a criticism of the project or the developers; as far as I
can tell, every non-trivial piece of software is likely to have bugs,
and bzr just does not have had the luxury of being around for long
enough; I mean, gcc does have bugs).


>
> One thing I would like to mention about Darcs, which was one of the
> show-stoppers for me. Was that it doesn't maintain an accurate history.
> Because of the "theory of patches", when you merge someone else, it can
> actually change the history of your branch.
>
> As an example:
>  I committed patch "A, B, C" in my branch, and then I merge you, where
> you committed patch "D". In bzr, this would show up as:
>
>   A
>   | \
>   B  D
>   |  |
>   C  |
>   | /
>   E
>
> My understanding of Darcs, is that it might decide to commute patch C &
> D, so that you end up with
>
>   A
>   |
>   B
>   |
>   D
>   |
>   C

Yes, and I think Darcs' docs do mention that you might end up with
patches in an order that is not the cronological order in which you
recorded them. Now, however, if I understood correctly, that
"reordering" can happen only if the reordering does not alter the
outcome. So one could say its OK, but I find it strange because _when_
I change certain things sometimes matters to me and I like thinking of
a file that actually existed in a certain specific state.



>
> This also has deeper implications when it comes to revision integrity.
> Because C might be changed by applying D, one cannot create a
> cryptographic signature for C. Inherent in the model is that revisions
> change based on what other revisions you have applied.
> I believe the benefit of this, is that you have more conflict free
> merges. The downside is a very large lack of stability.


>
> I do believe darcs has a lot of very nice things going for it. And I
> think we should keep and eye on it, and see what things we can
> incorporate. But I thought you should be aware of something I considered
> important, that I didn't see mentioned.
>
> But nice to see your 2006-05-05 post. Welcome to the group.


Thanks! My apologies again for the inaccurate statements. I've tried
to fix the page.



>
> John
> =:->
>
>
>
>


--
Ramon Diaz-Uriarte
Bioinformatics Unit
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz