[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
From: |
Aaron Bentley |
Subject: |
Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal |
Date: |
Sun, 31 Oct 2004 12:59:45 -0500 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040926) |
Matthew Dempsky wrote:
For what it's worth, patch-7 was generated by star-merging
address@hidden/tla--get-changeset-fix--1.3. Presumably under
the modifications to the process Tom has recommended, you would be
able to additionally know that. (Right now that's not evident,
however.)
I expect the necessary changes can be made by simply commiting a patch
to add =merges with all the versions I've merged patches from
If =merges lists address@hidden/tlasrc--devel--0.2,
I'll be screwed.
If patch-7 added address@hidden/tla--get-changeset-fix--1.3 to
=merges, I could:
1. download the changeset for patch-7,
2. find out that it added address@hidden/tla--get-changeset-fix--1.3
3. download the patchlogs for
address@hidden/tla--get-changeset-fix--1.3
4. determine that they merged patches that are already present in the tree.
It would be better if =merged listed the actual revisions merged.
It would be *much* better if there was a header in the patch-7 that
listed the revisions that had been merged, because then we could just
download the patchlog instead of downloading and parsing the changeset.
So it's a crying shame that we have such a header already, with tool
support and everything, but the header's been subverted.
Now, it's too late to add anything to =merges. It's not reasonable for
me to consult a later revision of tla--devo--1.3 to determine whether to
replay patch-7.
, or if
it's necessary to know in the individual patches I can undo all the
work I've done right now and remerge them.
That would be great. I'm sorry that you're stuck in the middle of this.
Aaron
- [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal, (continued)
- Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal, Mikhael Goikhman, 2004/10/28
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/10/28
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Aaron Bentley, 2004/10/28
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/10/28
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Aaron Bentley, 2004/10/28
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Matthew Dempsky, 2004/10/31
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal,
Aaron Bentley <=
Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Florian Weimer, 2004/10/28