My understanding of "changeset" functionality is that the "unit"
of change that is "committed" to the repository is not at the
individual file-level, but is instead at the logical-level and
would include all the edits to all the files that I modified
for a single coherent and consistent purpose (such as a 'fix'
or 'enhancement' or some other 'change task').
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.
Either way, the resulting cset-name can then be used as a tag of
sorts to refer to the set of files and their changes/revisions
hat were committed. And some would also say that they must be
"committed" as an atomic transaction.
I think the issue of 'order-dependency' is more of a function
of whether or not I chose to do my work on a new branch (and
hence check it out onto a new branch) or on an existing branch.
If anyone cares how BitKeeper does it (:-), BitKeeper
stores a change-set in such a way that it knows both the
context of the change, as well as what changed. Which means
the change-set involves metadata that tells me what files
and versions I changed, and which ones I didn't (it can do
store this 'efficiently' since all Bitkeeper workspaces are
first-class repositories). Perforce (with it's "jobs") and
ClearCase LT and UCM (with it's change-sets), and CM Synergy's
"change-packages", and Accu-Rev capture the set of changes
that were made (plus some other metadata). I think in all of
those cases, it is assumed that all the files "checked-out"
in the workspace participate in the change-set.
On Tue, Oct 08, 2002 at 01:53:41PM -0400, Greg Hudson wrote:
> On Tue, 2002-10-08 at 13:49, LOWE,DAVID (HP-Vancouver,ex1) wrote:
> > What I mean by "order-independent manner" is this. Two developers are
> > working on a code set. Developer A has a branch and makes and checks in
> > changes on his branch on Monday, Tuesday, and Wednesday. An SCM that allowed
> > "order-independence" would allow Developer B to apply Developer A's
> > Wednesday changes first and later apply the Tuesday and Monday changes.
>
> What's supposed to happen if Wednesday's changes depend on Monday's and
> Tuesday's changes? (For instance, if the developer created a file on
> Monday and then edited it on Wednesday.)
>
> If this is only supposed to work when there are no dependencies, then
> you can do it with CVS ("cvs update -j tuesday-tag -j wednesday-tag",
> then "cvs update -j base-tag -j tuesday-tag"). Perhaps there is some
> other requirement you haven't mentioned?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Brad Appleton <brad_at_bradapp.net> http://www.bradapp.net/
"Education is the ability to listen to almost anything
without losing your temper or your self-confidence."
-- Robert Frost
---------------------------------------------------------------------
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:16:57 2002