On 27.08.2017 02:09, Branko Čibej wrote:
On 27.08.2017 02:04, Daniel Shahaf wrote:
Julian Foad wrote on Fri, 25 Aug 2017 21:42 +0100:
Let's clarify. We can mean two possible things when we say 'a series of
patches':
1. "patch versions": a series of successively better patches, all
attempting the same logical thing, all from the same base, and only one
of which is applied at any time;
2. a series of patches, each providing a different logical change,
where each patch is based on the result of applying the previous one.
("quilt" is a tool for managing path series of this kind. My 'option 3'
(local repository) design for checkpointing could also be used in this
way, in a primitive way, but would not support revising earlier patches
in the series which is a key strength of what "quilt" can do.)
I am talking about definition 1 ("patch versions").
I propose patches in a series of patch versions be named "featureA-1",
"featureA-2", ... (This is what I do already, manually, in my own work.)
I propose that we should not attempt to provide any special support for
definition 2 within this "shelving" feature; users can manage that
themselves by simply remembering which feature names depend on which
other ones, or by including some other numbering system within the names.
Could you explain how you see this working? In use-case #2, later patches
in the series typically depend on earlier patches. I don't see how that
use-case
can be addressed if the patches are all implemented against deltas against
the same base (for example, because if patch #2 in a 5-patch series is edited,
all later patches would have to be regenerated).
If that's not clear enough I'd be happy to elaborate.
Cheers,
Daniel
P.S. I think brane's suggestion would make the "edit patch #2 in a 5-patch
series"
use-case a lot easier: diff3 is exactly the right tool for rebasing patch #3 on
top
of the edited #2.
Yes, that's one of the reasons I proposed storing whole files instead of
patches. Rebasing and reordering would become much simpler (although not
exactly "simple" if we take tree restructuring into account).
Another reason to store whole files: patches don't work with non-text
files. Which is a major problem especially on Windows where files often
are encoded in utf16.
Stefan
