Merge lp:~gary/launchpad/bug643715 into lp:launchpad
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~gary/launchpad/bug643715 |
| Merge into: | lp:launchpad |
| Diff against target: |
96 lines (+28/-9) 1 file modified
lib/devscripts/sourcecode.py (+28/-9) |
| To merge this branch: | bzr merge lp:~gary/launchpad/bug643715 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Aaron Bentley (community) | Needs Fixing on 2010-09-20 | ||
| Jonathan Lange (community) | 2010-09-20 | Approve on 2010-09-20 | |
|
Review via email:
|
|||
Description of the Change
This was just a quick itch to scratch as I was updating my tree after being away for a week. It makes calling update-sourcecode much faster.
To test, run
./utilities/
If you want to play around, you can change utilities/
I made a variety of changes for lint, even though some of them didn't make a lot of sense to me. I was surprised in particular by the preference for ('foo', ) over ('foo',). It's alright.
Gary
| Aaron Bentley (abentley) wrote : | # |
This branch treats revnos as if they were revision ids, which means that it may not notice cases where uncommit or push --overwrite have been used.
It also appears not to account for changes in the branch location.
It also assumes that "revision" is a revno, when other parts of the code treat it as a RevisionSpec instead.
| Gary Poster (gary) wrote : | # |
My change was an optimization for the common case. What we had already was "correct" for the edge cases you identified.
On one hand:
- I could make an additional change to handle the case of change in the branch location.
- We use revnos only, practically, so I think that's fine, myself.
However:
- I don't see how to handle an uncommit or an --overwrite.
I think those are pretty unlikely cases, but if we care about handling them, I think this is dead in the water. In that case, Aaron, isn't this actually a Rejected?
| Aaron Bentley (abentley) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/20/2010 04:03 PM, Gary Poster wrote:
> My change was an optimization for the common case. What we had already was "correct" for the edge cases you identified.
>
> On one hand:
>
> - I could make an additional change to handle the case of change in the branch location.
>
> - We use revnos only, practically, so I think that's fine, myself.
That's as may be, but it's actually faster and requires less code to
convert from revision_spec to revision_id and then compare to
wt.last_revision().
> However:
>
> - I don't see how to handle an uncommit or an --overwrite.
You could handle both branch location changes and revno redefinition by
auto-generating a list of revision-ids from update-sourcecode. The
output of this would need to be versioned.
> I think those are pretty unlikely cases
Also, there's merge trunk, commit, push to trunk.
But given that these are all PQM-managed branches and everyone who has
write access to them is pretty sane, I guess I'd agree that those cases
are unlikely.
, but if we care about handling them, I think this is dead in the water.
In that case, Aaron, isn't this actually a Rejected?
I think we can make it faster without making it less effective.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAky
jVkAn09Z9jlR13Z
=YDgF
-----END PGP SIGNATURE-----
Unmerged revisions
- 11582. By Gary Poster on 2010-09-20
-
make lint happy
- 11581. By Gary Poster on 2010-09-20
-
import missing exception
- 11580. By Gary Poster on 2010-09-20
-
optimize case in sourcecode update of already being on the desired revision.

Its preference for (foo, ) over (foo,) is wrong. Every linting tool that isn't pyflakes is terrible.
Thanks for doing this.