tortoisebzr-developers team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

C. Mundi wrote:
> Mark Hammond wrote...
> 
>> I've expanded on these thoughts a little at
>>> http://bazaar-vcs.org/TortoiseBzrContextMenu - including screen-shots of
>>> dialog mockups and a reference of every command TSVN currently provides.
>>  As
>>> noted at the top of that page, this is a straw-man - put up to be knocked
>>> down and to stimulate discussion.  I welcome all comments either here or
>>> directly on the Wiki page.
>>>
>>> Cheers,
>>>
>>> Mark
> 
> I like it.  Especially the update unification hybrid.  This addresses one of
> the most confusing workflow issues for new and infrequent users, even though
> the "correct" action is probably predictable in almost every case.
> J.A.Meinel has noted that some people really resist committing their work.
> I see that, too.  I also see that some people work for weeks before updating
> their branch.  That's just as bad (and often worse).  "Doing the right
> thing" by default will make it a lot easier to cultivate the desired social
> behaviors.
> 
> The problem of pushing changes or calling for a merge is a lot harder.
> Here, maybe TBZR needs a config switch.  Mode 1 is for people who are
> trusted to push their own changes.  Even here, there are multiple workflows,
> but just being clear that it's a push simplifies a lot.  Mode 2 is for
> people who have to ask permission/help to merge their changes back into a
> mainline.  Again, there are choices, but fewer than there would be if the
> modes were all combined.  Modes 1 and 2 are so different socially, that
> separate "modes" seem prudent.  The project leader would decide who's a Mode
> 1 user and who's Mode 2.  With expereince people might "graduate" to Mode 1,
> making everyone's life easier.
> 
> cm
> 

I would only point out that one of the strengths of bzr is that it allows
people to "violate authority". At least, it is a very big strength in the
open-source world where you don't get to play at the same level until someone
'approves' you.

Anyway, I fully support *assisting* people to streamline the workflow and
avoid confusion. I would sort of dislike making it seem like you can't do what
is really available. (Such as artificially disallowing users to branch to a
local branch that they can commit offline, etc.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFItA3rJdeBCYSNAAMRAngiAJ9ZQCkHmCYrXAuqzO7Etr4ifUioTACeKarE
2E2fcd1aziQxGFAI1CvXysM=
=yaut
-----END PGP SIGNATURE-----