> [Alice] can just tell [Bob] to grab changeset 53 (i.e. the unique
> patch applied at rev 53) from her repos. He can then merge
> the changes into his own repos whenever he feels like
> it. Right? Or am I missing the point of revision blobs?
B needs to record that merge in a format that A's tools can later
recognize so that later merges, back and forth between these two
branches, can be carried out intelligently.
Revctl. breaks down into a bunch of smaller issues, like naming
things, deciding exactly what a "changeset" is, and formatting logs.
Those issues, in turn, relate to much more than just revctl.
Bug tracking is an example. If A's changeset purports to fix a bug, B
(or B's "customers") should be able to issue a bug database query
about his revision that asks whether or not that bug is supposedly
fixed in his tree. A real-world application of this functionality is
illustrated by the recent slapper worm.
Red Hat (I've read) fixed the relevant slapper bug months before the
event -- but didn't have a unique name for their distributed revision,
or any kind of usefully machine-readable history of patches. People
who didn't read their changelog but went only by the revision name
thought, at first, that the bug had not been fixed. It could have
happened the opposite way: reusing a revision name _without_ picking
up the bug fix -- which would have given some users a false sense of
security.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 10 07:45:28 2002