[MERGE] Speed up diff spec handling.
John Arbash Meinel
john at arbash-meinel.com
Fri Apr 25 00:56:23 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> Actually, I explicitly did *not* want to fetch.
>
> I want it not to fetch too, but I want to use it even more than I want
> it to not fetch. And I can't use it in its current state.
>
>> There are other specs
>> which can reference a revision_id that is not present, and is not
>> accessible. (-r-1:../other_branch as an example).
>
> That is not an example if "not accessible", as I mean it. The revno
> spec provides a branch location, and that branch location can be used to
> access the revision.
>
> The branch spec does not provide a branch location. This means that
> while you can do as_revision_id, there's no reliable way to retrieve the
> associated tree.
>
>> I would rather leave branch: as not fetching, rather than continue to
>> have all the lock_read/write bugs of having a revision spec mutate its
>> branch and repository.
>
> The "branch:" spec needs to be in one of two modes:
> a) provides a branch location, does not fetch
> b) fetches, does not provide a branch location
>
> It is currently in neither mode, because sometimes it fetches, and
> sometimes it does not, but it never provides a branch location.
>
> This means that its RevisionSpec_branch.as_revision_id() is not a
> substitute for RevisionSpec_branch.in_history(some_branch).rev_id, which
> contradicts the rationale you gave for implementing it.
>
> Aaron
I would rather it provide a branch location than fetch. So if it can be
(a) or (b), then I would chose (a).
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIER4nJdeBCYSNAAMRAgIPAJ47BZS86zvO2gfGZyVv9SGaXvKoYQCggE7Q
joq+Eavaymd775ZxL/cv2e0=
=HrYi
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list