How to get the diff between two arbitrary remote revisions?

[John A Meinel]

Kevin Smith wrote:
> Kevin Smith wrote:
>> With hg, a branch can contain multiple heads, and the working tree can
>> be checked out from any of them, or from any other version in the
>> history. Typically you would reposition the working directory by
>> specifying a tag name, although you can give a revision hash.
> 
> I wanted to clarify that I'm not advocating that bzr move in the
> direction of hg. In fact, my current thinking is that the hg hybrid is
> worse than either of the more pure alternatives. I tend to prefer that
> there be one obvious way to perform a task, rather than the two that hg
> offers.
> 
> An hg user has to decide whether to create a new microbranch within the
> same branch, or to create a whole new branch. Generally, I would
> probably keep bugfix forks in the same hg branch, but use separate hg
> branches for feature development. That's partly because hg lacks any
> other way to have cheap branches on non-hardlink systems.
> 
> I've mentioned it before, but that's one of the key features I want from
> bzr, and I'm hoping repos will provide it. I'm not familiar enough with
> the technical details to understand the various proposals going around.
> Last I heard, some form of centralized storage or shared history was
> still a goal of bzr. I hope this feature is still on a front burner and
> will be part of the initial repo implementation.

Yes, repositories will use shared storage. I think we're still trying to
be flexible to allow different people to have their own preferred
workflows (for example, we are avoiding defining a namespace for
repositories, but letting people define their own.) Where possible, we
will probably present a "best practices" rather than institute an
required policy.
So there might still be a "more than one way to do it", but when
possible we'll try and give a recommended way.

> 
> I'm eager to push bzr adoption at work, and cheap branching is one of
> the blockers. Good MS Windows compatibility is another (I'm not quite
> sure where that one stands). The only other thing holding me back is a
> bit of nervousness about the ongoing speed of change
> (weaves...repos...what's next? knits?). Oh yeah, does bzr have tagging
> yet? Well, and having bzr available via apt for hoary. I guess it's not
> such a short list after all :-(

We have a form of tagging implemented, but it is something that is still
in discussion about how to do it correctly. I think it got discussed at
UBZ, but I wasn't part of the discussion.

bzr is already available in breezy, and I believe the dailies might
become available in dapper. I think they are punting for now with hoary,
since we decided to require python2.4 (it cleans up some stuff, and
development speed is top priority right now).

Yes, the development speed is quite breakneck. I remember having to
refactor my Transport code 3 or 4 times because I left it for < 1 month.
(It was pretty invasive of certain parts, though). But we are still
pre1.0, and we want to get everything "correct" rather than maintaining
absolute compatibility. Far better to do the right thing early and break
compatibility than to be stuck with cruft for a long time.

I think right now the best thing is to get new users slowly, so that we
are reminded of what needs to be updated, before things start to get
really crowded.

John
=:->


> 
> Cheers,
> 
> Kevin
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051118/193ef809/attachment.pgp