How to get the diff between two arbitrary remote revisions?

Jan Hudec bulb at ucw.cz
Fri Nov 18 20:20:12 GMT 2005


On Fri, Nov 18, 2005 at 11:44:16 -0500, Aaron Bentley wrote:
> Jan Hudec wrote:
> > Aaron Bentley wrote:
> >>That looks pretty alien to me.  I can't see why you'd want to commit
> >>against a hash fragment, rather than a branch name.
> > 
> > 
> > Because it does not have the name yet?
> 
> But if all it has is a hash, it's pretty hard to find what you want, anyhow.

It's equally hard in bzr! If I want a thing that does not have a name, it
does not matter in what system it does not have it. Most probably it's going
to be found by reading the logs.

> > Basically say I have revision r in branch X, but not it's head, and I want to
> > try something against it. So I do bzr branch -r r X Y. But if I don't want to
> > copy over all the data, it's two steps for archive branch (branch and
> > checkout). 
> 
> Well, depends what we do.  Personally, I'd like a way to do
> branch-and-checkout in one step.

So do I. But since it's supposed to be a micro-branch, not copying the
history would be nice, which makes it a use-case for either shared storage
(the older proposal, without naming branches) or a branch-and-checkout
command (or rather option to checkout).

Actually, writing this message I though of a slightly better way. See below.

> Anyhow, didn't mean to critique Hg, just was having trouble
> understanding what it solved.

Well, I don't think it really solves anything. I was just confronting the
approaches because I was not sure which points are sane and which are not.

Because basically the branch-working-tree coupling is fundamental in Darcs
(where a revision is defined as a set of patches, the wokring tree needs to
keep it around and since repository would be just a set of patches, unifying
them is natural). But with history lines, the unification is not natural --
and I wanted to sort out when it makes sense.

By the way, I think it does *not* make sense the mercurial way. When the
repository and the working copy are not tightly bound, they don't need to
live together. What I think does make sense is monotone way, where there is
a shared storage, from which you can check out any revision present and
create revisions based on that.

The bzr branches mostly do that, except they require naming branches before
you can commit to them. Therefore I suggest following options to commands:

# Let's say there are 1359 revisions on /repository/some/branch:
bzr checkout -r 1234 /repository/some/branch
<hack, hack, hack>
bzr commit -b /repository/new/branch
# Now this would do:
=> bzr branch -r 1234 /repository/some/branch /repository/new/branch
=> modify the dirstate so that it is now checkout of /repository/new/branch
=> bzr commit

That way all branches would be named, which is good for general sanity, while
microbranches would be reasonably cheap.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051118/5260ebce/attachment.pgp 


More information about the bazaar mailing list