Re: Svn as a changeset engine.

Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> Does this jive with what other people think of as a changeset engine? Would
> implementing some of these ideas post-1.0? Does this enable a lot
> that is not supported by private developer branches (assuming
> variance-adjusted-patching), where the user can selectively merge
> changes into their branch?

This does pretty much jive with my understanding too, yes. (Would be
interested to hear from some people who have actually worked with
changesets, though!).

Note that a `change' can be a subset of a revision. For example:

   Revision 12
   ===========
     edits /foo.c in five distinct places
     adds /docs/bar.txt
     deletes /www/qux.html

We could consider revision 12 itself to be a change (call it "r12").
But we could also consider any of the individual operations in that
revision to be a change, if we want to be more fine-grained about
things. In that universe, here are some potential change names:

   r12:{/docs/bar.txt,/foo.c}
   r12:{/foo.c,/www/qux.html}
   r12:{/foo.c,/www/qux.html,/docs/bar.txt} (<-- equivalent to "r12"!)

You get the idea. I won't even go into the level of granularity that
distinguishes the five changes within foo.c -- let's just stick to the
file-level for now :-).

So if later r13 also edits qux.html in the same places, we don't need
to say it's dependent on r12, it's only dependent on some change like:

   r12:{..., /www/qux.html, ...}

It'd be nice if our metadata system were flexible enough to handle
things like this.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 20:44:10 2002