Tom Lord wrote:
> One of the things I've been hoping to call svn developers' (and
> potential users) attention to is that a changeset engine is not
> naturally layered over a version control system which is not a
> changeset engine. (For example, Larry McVoy has oft repeated that it
> took an amazing _$12M_ to build BK whose storage management strategy
> predates changeset management concepts -- a slightly biased
> characterization of his statements, but not completely unfair. Indeed
> - so far as I know, the (imprecisely defined) distinction between
> "changeset management" and "version control" originates with Larry.)
>
> Changeset manipulation has implications all the way down. Once you
> adopt it as an important design concern, it can guide your decisions
> about storage management, often in simpler directions (e.g., file
> properties are not needed or desirable -- so questions about how they
> should work can be avoided). In the case of svn, it looks to me like
> you need less work than what you're doing and planning, but then some
> things that are different from what you're doing.
This has been a very intersting thread to read, but the above has me puzzled.
I'm wondering if multiple definitions of "changeset" are in use. A little
googling has led me to:
... changes to multiple files into a single unit of work (a changeset) that is
itself revision-controlled. (from the BK site incidently)
The way I read the above (and a few other posts), it appears that a different
definiton is in use because it appears to me that SVN already does this, yet
some posts (e.g. the quote above) discuss SVN like it doesn't.
Can someone help my confusion? :-)
Thanks,
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 19:06:39 2002