> What you are proposing is a set of policies, or best practices that a
> revision control system should enforce, not for better or worse, but
> because you want to lead users of the system into what *you* think is
> the proper way to handle revisioning in a distributed environment.
You have misunderstood me.
The issue at hand, change sets and their relation to the user
interface, is largely orthogonal to the the issue of distribution.
A revision control system:
1) Stores and catalogs change sets made explicitly and
intentionally by users.
That collection of change sets forms what you might think of
(pseudo-algebraicly) as a basis set. There are two operations, "diff"
and "patch" (or "deltapatch" or some other equivalent), whose domain
includes that basis set. That brings us to the second function of a
revision control system:
2) To be able to construct-on-demand the "span" of the users'
change sets under the diff and patch operations.
`update', `merge' and other operations (however you spell them) are,
it seems to me, most clearly understood as special cases of function
(2) --- not as "that stuff that CVS does" (sorry - cheap shot).
`arch' is attempting to nail (2) with a fully general operation
(delta-patch) and some handy special cases (star-merge, update,
replay).
These two functions play off of one another. The nature and structure
of the change sets collected by function (1) has deep impact on the
usefulness and "shape" of the space reachable by (2). The idea of a
"clean patch set" is not (merely) some (generally positive)
anal-retentive project management strategy -- it is a way to enhance
the usefulness of function (2). More specifically, if I have nicely
isolated changes, that gives me more useful points in the space of
revisions reachable by function (2).
It'd sure help to be able to draw pictures here -- I'm aware that the
verbal description is pretty tricky to follow. Alas, we lack a
convenient media for that.
There are plenty of secondary, external reasons to want clean patch
sets too -- though you already know all that (judging by how you
(collectively -- i don't keep track of who does what) manage the svn
project). For example, as you have continuously demonstrated for as
long as I've read the dev list, clean change sets are easier for other
people to review in detail. But, as you say, that is all arguably
just policy -- not something to enforce.
The more fundamental reason for clean change sets is the play-off
between functions (1) and (2) above.
Ok, distribution is *mostly* orthogonal to that. How is it not
orthogonal? Well, distribution is interesting to us because, after
all, there are lots and lots of programmers in the open source world,
working at lots of different sites. They collectively produce a lot
of change sets (non open-source development isn't all that different).
While function (2) may have been occaisionally interesting for small
teams, for large teams, it becomes much more important.
Watching myself and others work, I have noticed that it is very
difficult using plain trees, a CVS-style system, or the (current) arch
user interface to produce clean change sets. The amount of manual
bookkeeping is too high and, luckily, it can be automated away.
The question here is, can we make a user interface that just makes it
fun, easy, and personally rewarding to produce clean change sets,
without having to rely entirely on some butch who reads the check-ins
and kicks back the messy changes or tweezes them apart with
after-the-fact tools. My answer is yes:
arch is already a large part of the way there, I think. The way it
logs merges, for example, helps a lot. I keep kicking around some
ideas for idempotent merges that might also come up again.
The biggest element missing in arch (in this area) is a working
directory librarian. The easiest way to make sure a change set is
clean is to make every change in a separate tree. Alas, some adjacent
tools (e.g. vi and emacs) don't support this well -- yet.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 06:14:52 2002