tortoisebzr-developers team mailing list archive

["Mark Hammond" <mhammond@xxxxxxxxxxxxxxxx>]

Hi Carlos, and welcome to everyone else who has joined this list over the
last few days.

> I am new to bzr but not to vcs.  I've been experimenting with bzr for a
few weeks, 
> trying it out,  mostly on the command line, and I like it. Without taking
anything 
> away from the fine efforts of the QBzr or bzr-gtk folks, I think that the 
> TortoiseSVN team has hit upon some good things (and maybe some things that

> can be done better too) which can make bzr more accessible to all of us
who 
> use WIndows, whether by choice or otherwise.  I'm not sure how much code
I'll 
> be able to contribute.  But I'm looking forward to helping out with
usability 
> testing and docs where I can.

That is excellent - nice to see you :)

> Mark Hammond has already posed a question, as if he read my mind. 
Paraphrasing: 
> Should the TortoiseBZR menu present options which depend on the contents
of the 
> directory [or depending on the currently selected file(s)]?

Yes.  Some cases seem easy (eg, "don't show 'Add' if the item is already
versioned"), but its not always so simple.  bzr itself also offers
challenges that svn doesn't (eg, bzr could find a branch, a heavy checkout,
a lightweight checkout, etc) - so its not only attributes of the selection
that's important, but attributes of the branch/repo/etc.

> This is something which I would very much like to see, and it's something
that the 
> TortoiseSVN folks don't get quite right (yet) in my opinion.

They actually try very hard to get it right.  They have a fairly
sophisticated mechanism for using the state of selected items etc to
determine what to display.  This isn't to say they get it right all the
time, but the mechanism is used and can express some fairly complex
conditions.  For example, the "add" command in tortoise is shown if "a
non-versioned item in a versioned directory is selected, or if a versioned
folder is selected, or an ignored item, or a deleted item that isn't a
folder".  So any problem TSVN has in this area is more about trying to match
the user's expectations than about lacking a mechanism to adapt to the state
of the selection.  That is a key challenge for us too.

More generally, I see 5 distinct challenges (ie, opportunities to get
involved ;) for TBzr

1) Design of the context menu, in terms of the commands that are available
for any given item - ie, exactly the point above.  As mentioned, bzr
introduces its own challenges - eg,  if we know a directory is already a
checkout, do we want to offer "pull" at all?  Maybe there should be a
generic "Update" item that "does the right thing"?  This is actually the
least technical, but the most abstract, and the most important for
Tortoise's success IMO, so I'll take this up in more detail in a separate
thread.

2) Managing a custom UI on top of QBzr.  Specifically, QBzr is designed to
be run from the command-line, and the user explicitly specifies a command
(eg, 'qbranch').  If we do anything like (1) above (eg, a generic "update"
item), we will need some custom UI that isn't really applicable to QBzr
itself.  This will probably come directly out of (1), although some can be
identified now (eg, a user-interface for managing the TBzr user-preferences)

3) Tweaks and polishing of QBzr itself: QBzr is looking very nice and the Qt
UI model looks very reasonable.  It does lack a little polish in some areas
though, and other commands are yet to be implemented at all - although many
of these are ripe for easy-picking.  Things that spring to mind are having
the combo-boxes remember previously entered values by the user, 'qupdate'
command for checkouts, etc.  These items are largely independent of the
other items and can be best summarized simply as "help enhance qbzr".  If
you are interested in helping out in this area, I'm sure the QBzr guys would
love to hear from you with your ideas.

4) Continued implementation of TBzr itself: stealing TSVN's icons for the
menu commands, implementing the shell extension in C++, helping Dave with
the "directory watcher", shell notifications, making the binary setup
process more modular, etc.  In the ideal world, this is where I would spend
most of my TBzr time, but everyone is welcome to pitch in - please contact
me if you would like to help here (and I hope to be spending more time here
very soon, helping merge Dave's changes etc...)

5) Documentation, including TBzr specific documentation, and better generic
Bzr documentation, especially for concepts that might be very hard to
express in a clean dialog.  This would ideally include the ability to link
directly to relevant help topics from various places in the GUI.

Each of these offers plenty of scope to get involved too.  As mentioned,
I'll go into more detail on item (1) later (probably in 24 hours or so), but
if anyone would like to discuss any of these items (hopefully with the aim
of contributing to them), please do!

Cheers,

Mark