On 1/16/07, Daniel Rall <dlr@collab.net> wrote:
> The typical case where I require overlapping change sets is for a
> refactoring opportunity or requirement encountered while working on
> some other feature. For example, while working on JavaHL's logging
> code, I suddenly realize that in an error situation I need to throw a
> specific type of exception, for the case where the logging code is
> invoked from JavaHL's the SVNAdmin class instead of its SVNClient
> class. Unfortunately, previous to r22985, JavaHL's exception factory
> code would only throw ClientException. So I refactor the code to
> allow me to specify the exception type to throw. Unfortunately, both
> the logging code and the exception factory code are in the JNIUtil C++
> class! So the change that I started making first needs to be
> committed second, and depends on another change in the same file I
> completed while working on the initial change.
This is the common case for me, too. I often have multiple changesets
running at once (I mean conceptual changesets -- not using the
"changelist" featue, just squirreling away patches and doing the CMike
workaround). This is usually because while working in a file to solve
problem A, I encounter problem B, and then in the course of solving
B encounter C, etc. Naturally, A, B, and C all deserve separate commits.
I'm not thrilled with the changelist feature as it stands, because I think
we've put into the libraries something that really belongs in purely client
code. For example, suppose I were using an Emacs interface to
Subversion. I could easily write the changelist feature without changing
a line of code in Subversion itself: just give my file-management interface
the ability to put files in groups and name the groups. Then later, when
I want to add hunk-level management, I just have Emacs start remembering
which hunks of a given file's "svn diff" output are included in a given
change group, and when committing, do the following: save the working diff
for the entire file, revert the file, pull out the appropriate hunks from the
saved diff, apply them to the working file, commit, then (re)apply the
remainder of the patch. Voilą! Hunk-level changelist control, and not a line
of code in Subversion affected.
The point here is not Emacs (or Eclipse, or TortoiseSVN, or 'svn', etc), of
course -- it's clients in general. *Everything* needed to implement any
reasonable definition of a changelist feature can be done purely in client
code. So why are we starting by doing it in the libraries?
"Aha", I hear someone object, "But why make all the different clients
implement this, when we could implement it in Subversion and save
them the trouble / make the feature consistent / do it most efficiently /
etc?"
That argument doesn't apply as well to the changelist feature as it might
to other features. Changelists are all about interface anyway -- most of
what's involved in getting this feature right falls on the interface side of
the code. The rest is trivial, because it just involves passing lists of files
to existing Subversion library APIs. All those APIs already *take* lists
of files. You want 'svn diff' to be changelist-sensitive? Well, if your
client is changelist-conscious, it'll just pass the files of the currently-
active changelist when it invokes the diff APIs. It's not like tons
of potential
client code is getting factored away by us putting this directly in Subversion;
most of what clients would have had to write, they'd still have to write.
And taking the long view, we're failing to take advantage of "the laboratory
of the clients" by stuffing this into Subversion now. Even if it eventually
makes sense to have changelist support directly in Subversion, I think we'd
find out how to do it best by seeing how lots of clients implement it, and
adjusting our APIs to support their needs first.
If we're going to ship native Subversion with changelists, can't we put them
in the 'svn' client first (it can use the config area for bookkeeping), and not
make irreversible changes to our APIs and the .svn/entries file? Then we're
just another client, and we can experiment with stuff without worrying about
permanently mucking up our APIs.
None of this is an objection to the feature itself, by the way. I love
changelists, they're great, they make the sun shine and the grass grow
and the mitochondria oxidize. Yay, changelists.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 01:07:28 2007