Brad Appleton <brad@bradapp.net> writes:
> So maybe when I did a "commit", there would be a way to identify
> the change-set: either I specify the name (or cset identifier)
> and svn would imply that it means all the files that I've
> checked-out in my current workspace, or else I specify the
> cset-name and the set of modified files, and only those files
> are committed to the codebase.
Subversion has changesets, but they're sort of implicit. Each
subversion commit *does* have a unique name -- the revision number.
We can examine subversion's "changesets" by looking at the diff
between any two revisions. We can also apply a "changeset N" to a
working copy in any order by running 'svn merge -r N-1:N'.
The difference between svn and a true changeset system is that we
store the trees as first-class objects, and the changesets are
derived. If I understand correctly, a pure changeset system stores
the *changesets* (i.e. patches) as first-class objects, and the trees
are derived artifacts that come from mixing and matching them. I
think this is how Bitkeeper works, no?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 8 21:26:44 2002