[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