On Feb 18, 2004, at 6:13 PM, Greg Hudson wrote:
> The primary question is what is the best way to model the data in a CVS
> repository. I don't think the answer to that question should be driven
> by producing similar operational behavior to what CVS did on the data.
>
> Put another way: if you "svn add" a file, then "svn rm" it, then "svn
> add" the same filename again (committing after each step), an svn log
> on
> the filename will only show the new incarnation. That's different
> behavior from CVS. Should CVS users see one behavior on the data they
> had in their CVS repositories, and another behavior on data they have
> created since?
Well, should CVS users see one behavior on the data they committed
before the conversion, and a different behavior on the same data after
conversion? There's a tension here: should this troublesome data be
converted "as similar to the past as possible" or "as similar to the
future as possible"? I think past data will be associated with
understanding, assumptions, habits, procedures, and scripts that
reflect the former behavior. All of these _can_ be changed, but we
usually have more urgent things to occupy our time.
It may simply be that ghudson and I are expressing preferences from
different backgrounds. My reflexes are all in enterprise development,
which is populated with a majority of people who have no time
(sometimes, even skills) to understand and think through, the history
of code and the wonderfulness of the new system; they need their job
reduced to routine. In some other circles (open-source development and
academic are both examples, I think), we have a reasonable expectation
of both skill and motivation to get to the heart of everything.
> The primary question is what is the best way to model the data in a CVS
> repository. I don't think the answer to that question should be driven
> by producing similar operational behavior to what CVS did on the data.
Well, when you talk about "model," you already lose 75-90% of the
enterprise development community. A "model" is something you
understand first, and only then begin to predict what the system itself
will do. Their "model" is their procedure document, or memorized list
of steps and tricks. I think this concern for "the best model" has
some idea rather like "a model which makes coherent sense in the large;
is consistent throughout; allows inferences in one area based on
knowledge from another." These are fine goals, I'm not knocking them,
but they're not the goals of the "nose to the grindstone, directions in
one hand, one check-list item at a time" community.
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 23 21:39:53 2004