These notions that one can always best answer questions by looking at
the content, and that "Individual files DO NOT EXIST" seem over stated,
to me.
Granted, overstated for a good reason. A couple sticks of dynamite are
needed to shake loose some old SCM thinking habits.
===
Ingo has a point when he states:
> i believe the fundamental thing to think about is not file or line or
> namespace, but 'tracking developer intent'.
He too overstates - it's not _the_ (as in one and only) thing.
But it's useful. Given the traditional terseness of many engineers,
it's certainly not the _only_ thing. The code speaks too.
===
The above two are related in this way. Traditional SCM uses per
file (versioned controlled file, as in s.* or *,v files) metadata
to track 'developer intent'.
I'm afraid we are at risk for confusing baby (developer intent)
and bathwater (version controlled file structure of classic SCM's).
===
But we already have a pretty damn good way of tracking developer
intent that needs to fit naturally with whatever we build on top
of git.
Mr. McGuire: I just want to say one word to you - just one word.
Ben: Yes sir.
Mr. McGuire: Are you listening?
Ben: Yes I am.
Mr. McGuire: 'Patches.'
# the original word was 'Plastics' - The Graduate (1967)
Andrew and the other maintainers do a pretty good job of 'encouraging'
developers to provide useful statements of 'intent' in their patch
headers.
The patch series in something like *-mm, including per-patch
commentary, are a valuable part of this project.
===
I have not looked closely at what is being done here, on top of
git, for SCM like capabilities. Hopefully the next two questions
are not too stupid:
1) How do we track the patch header commentary?
2) Why can't we have a quilt like SCM, not bk/rcs/cvs/sccs/... like?
For (2), anyone publishing a Linux source would periodically announce an
<sha1> value, attached to some name suitable for public consumption.
For example, sometime in the next month or so, Linus would announce
that the <sha1> of 2.6.12 is so-and-so. That would identify the
result of applying a specific set of patches, resulting in a specific
source tree contents. He would announce a few 2.6.12-rc* <sha1>'s
between now and then.
Between now and then, Andrew would (if using these tools) have published
several <sha1> values, one each for various 2.6.12-rc*-mm* versions.
If you explode such a <sha1> all out into a working directory, you get
both the source contents in the appropriately named files, and the
quilt-style patches subdirectory, of the patch series that gets you
here, starting from some Time Zero for that series of published kernel
versions.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
