> From: Daniel Berlin <dberlin@dberlin.org>
> > Right. And the interesting things about looking at the relationship
> > between "whole project tree" merges and their relationship to business
> > rules and project managment is that:
> >
> > 1) Whole project tree merging is a good fit for reasonable business
> > rules/project mgt. People don't talk about "the GCC patch to
> > files so and so" -- they talk about "the [implicitly: whole tree]
> > patch to GCC that adds feature X or fixes bug Y".
> Say what?
> This is a bad example.
> People talk about patches to files so and so all the time in GCC.
> Unless you are changing something about the actual intermediate
> represenation in GCC (IE reducing the size of the tree structures by
> moving members around, etc), or adding macros to *all* targets (or all
> configs of a target), generally, you don't touch more than maybe a few
> files.
> That would be madness in terms of trying to find bugs if most patches
> didn't touch < 5 files.
> Pick a different example.
I think you just misunderstood me.
When I say "whole tree patch" I don't mean "a patch that touches all
or most files" -- I mean the same kind of patch you're talking about:
a logically unitary change, large or small enough to suit the
particular process for which it's used (e.g., small for _most_ patches
that will be reviewed or applied to mainline or a development branch;
large for patches that sum up all the changes between two releases).
By saying "whole tree", I mean: (1) That there is a substree of the
overall project which is reasonably regarded as a "project tree" --
the whole project being a union of a few project trees. (2) Those
project trees are the granularity of development lines. For example,
if I'm hacking GCC, 99/100 times I will check out entire project trees
rather than just the 2-3 files I'm going to change because I'm going
to build and test the project tree. If I form a development branch or
release branch, I'll branch with project-tree granularity. (3)
Project trees are the primary granularity of processes like review
policies and patch flow and release management -- you can understand
patch flow into the mainline as patch flow organized with project tree
granularity. (On that last point, yes there may be special-cases
rules for certain files within some project trees -- but those are
just a special case of special rules based on the nature of a patch:
merge history and patch flow is still organized at the project tree
level.)
Looking at GCC from the maintainer or project manager perspective, or
the perspective of a 3rd party distributor of GCC, or the perspective
of a GCC consumer: I don't ask "Have those instruction scheduler
changes been merged into gcc/foo.c?" I ask, "Have those changes been
merged into branch so and so or release such and such; Has feature
XYZZY appeared on the mainline yet?"
Yes, patches are generally small and programmers pay attention,
especially when reviewing, to which files are touched -- but the
administrative handling of patches, _including_the_merge_history_, is
at the "whole project tree" level.
(It's a separate question whether GCC is most reasonably regarded as
one huge or a few smaller project trees.)
And, hmm.... just as an aside. I woke up this morning realizing that
if you had first class project trees in svn, suddenly a fast,
space-efficient, native-fs storage manager would be a lot more
practical (i.e., no need for BDB or a RDMS). Not trivial -- but
tractable.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 13 18:19:31 2003