tortoisebzr-developers team mailing list archive

[Alexander Belchenko <bialix@xxxxxxx>]

[Sorry, now reply to list too.]

Side note: I don't use TortoiseSVN, because after 3 years
of bzr command-line experience I no more fear command-line clients,
e.g. svn.exe. But before bzr I'm using TortoiseCVS very heavily,
so all my Tortoise experience based on this. Please, bear with me
if I'll talk something unrelated to TSVN.

Also I should admit that I'm working with TCVS in very similar manner
as with bzr: I've created many feature branches and did many merges.
And TCVS very often did merge right. I guess it's because under the
hood cvsnt was used, not original cvs. cvsnt has/had some improvements over
plain cvs.

Mark Hammond пишет:
> Alexander writes:
>
>>>  Maybe there should be a generic "Update" item that "does the right thing"?
> ...
>> Even if I'm working in the checkout I'm still able to do pull from
>> another (different from master) branch. I'm not sure what you call `generic "Update"`.
>> Pull is valid operation for checkouts and it's not the same as update.
>
> I think this gets to the heart of the matter, especially with a tool like bzr that offers so many possible workflows 
and options.

Yes, too many workflows and too many choices is not always good thing but often bad thing too,
as stated by many users (some of them chose hg because of this).

> It seems that a very common operation that a user will want to perform is
> "update this directory so I've got the latest changes others may have made".
> If I'm working in a checkout, that will usually mean I want to perform an update.

I'm agree.

> If I'm working in a regular branch, I probably want to perform a pull -
> but sometimes the distributed version of bazaar means I may actually need to perform a merge/checkin.

Yes, it's true.

> The question is: do we want to expose all this to the average Tortoise user?

Probably not. Because Tortoise very often means "merciful human interface for mere mortals".
(Am I right?)

> Should "Merge" appear on every context menu to cater for this possibility?

I think it should. There is nothing bad in Merge. When I'm working with TortoiseCVS
I remember that Merge was exposed in second section of context menu (first section
was often used commands, next sections -- less used commands). Why not?

> If we do, then we also expect the Tortoise user to *understand* the various differences,
> and when to use them.
> I'd suggest a better approach might be for Tortoise to cater to the "common" use cases,
> leaving the advanced use cases for the command-line client,
> or otherwise suitably "hidden" from the casual bzr user.

Why not just divide commands to "sets" or "sections", and expose most useful always,
and more "scary" in submenu?

> For a concrete example of the potential confusion:
> Personally, I'm still not 100% sure about the use-cases for doing a pull on a branch.
> Below is a (slightly snipped) transcript of a conversation on #bzr on the 17th (times are +10) -
> I was enquiring about the lack of a '-r' option to 'bzr up',
> and thought that it might just be "spelt" differently in bzr than svn:

IMO this confusion due to fundamental difference in internal models of svn and bzr,
but using the same or similar commands for similar but not fully equivalent actions.

To understand your confusion I need to understand why you want to execute `update -r`.

> (11:14:35 AM) markh: how do I update my checkout to an earlier revision of the branch?  I was surprised to find no 
'-r' option to 'bzr up' nor to bind.
> (11:15:17 AM) beuno: markh, I don't think you can, since it's bound to the other branch
> (11:15:29 AM) beuno: you could branch off of it at that revision
> (11:15:31 AM) markh: so update the branch, then up the co?
> (11:15:43 AM) pygi: markh, bzr pull --overwrite -r 8214
> (11:15:45 AM) pygi: perhaps :p
> (11:16:34 AM) pygi: markh, helped? :)
> ...
> (11:18:02 AM) beuno: I think generally you'd branch -r off of it
> (11:19:47 AM) markh: So what's the difference between "pull" (with no args) and "up" once you have a checkout?
> (11:20:15 AM) markh: (I'm working with checkouts on a test machine, with the branches being on the main dev machine)
> (11:20:56 AM) pygi: bzr pull is nicer in some cases :)
> (11:21:09 AM) markh: heh :)   what's the conceptual difference?
> (11:21:12 AM) pygi: well, anyway, they have different use-cases
> (11:21:21 AM) pygi: bzr up will do a merge

^-- not necessary but it's not quite correct.

> (11:21:23 AM) pygi: bzr pull won't

^-- it's not quite correct.

> ...
> (11:31:17 AM) fullermd: Using pull in a checkout to adjust your working copy is totally not what you want to do...

> Note the general confusion between people who you would expect would know (obviously including me).
> Note that last comment - it makes me concerned that, eg, exposing 'pull' on the default context menu
> of a checkout might be asking for trouble.

So it's the candidate for "expert" set of commands there.

> So while there is a use-case for using pull on a branch,
> is it a use-case Tortoise needs to cover?

IMO, for branch -- yes. For syncing with lp:branches for example.

> This isn't a rhetorical question - I'm searching for the answer - or failing that,
> the most suitable middle-ground :)

I'm trying to understand your confusion, but I have not your svn experience,
but I have a lot of bzr experience, and I'm starting to use bzr in its early
days, so I'm learn all this workflows naturally when they grow up.
In early days there was no checkouts support, only standalone branches.
Then shared repositories appears and later checkouts/lightweight checkouts (IIRC).

I guess there is 2 different major workflows: branches and lightweight checkouts.
The latter is most closer to CVS checkouts. [Heavyweights] checkouts is in the middle
between former and later. And they sometimes produce confusions. A lot of confusions.

I'm using checkouts at my job just to get the following behavior:
all my changes automatically mirrored to server.
I have checkouts for trunk branches of our subprojects, but
new features I'm trying to develop in local branches. When I'm ready to put my
work to trunk I do pull/push or merge between trunk checkout and feature branch
(i.e. I don't follow bzr.dev style of development where only merge to trunk is possible).

Does it make sense as one of possible workflow?