Re: changelist feature -- keep it? tweak it? scrap it?

On Tue, 16 Jan 2007, Ben Collins-Sussman wrote:

> My understanding is that Dan Berlin and Dan Rall have been using the
> feature, and in fact were the ones screaming for it when I first
> proposed the idea. I also thought that Justin was using it. Anyone
> else?

> Stefan: it sounds like you've just made an argument against all
> distributed version control systems. "Oh no! People will hold on to
> private changes for too long!" :-) Consider this: a changelist
> sitting in an svn working copy has no history to it. If thousands of
> fans are busy switching to distributed version control systems and
> creating multiple private copies of repositories, I don't think the
> ability to manage shallow patches in a working copy is a real threat
> to 'best practices'.

Yeah, this is the opposite of my working style. I typically have a
bunch of changes going at once across several WCs. Personally, I
consider it bad practice to type 'svn commit' with no explicit
targets, as an urge to do that often means that I haven't done enough
pre-commit review of my changes.

> Similarly, I find it odd that CMike saying that he feels guilty about
> working on two changes at once. It's completely normal to have
> multiple patches in progress, especially on totally different parts of
> the tree. It's just another form of multi-tasking -- like running
> multiple applications on your computer. There's nothing morally wrong
> or sloppy about it. And it's a really, really common scenario.

Hmmmmm. With the state of today's tool set (including the changelist
feature), it's best to keep related changes segregated in separate
working copies to avoid unexpected side-effects when commiting one
change set without another. Strictly speaking, it's the *unrelated*
changes with unexpected side-effects which makes separate WCs a better
idea.

> As DannyB said, it's usually about efficiency. Archiving and
> unarchiving a patch with diff/patch isn't always convenient, and it's
> also not convenient to just create a new working copy everytime a new
> task comes up.
...
> - there is a single optional field in the entries file:
> "changelist='foo'", settable by the 'svn changelist' subcommand.
>
> - 'svn status' notices the uses the field to display file groupings
>
> - 'svn commit' and 'svn revert' take optional '--changelist'
> options, which uses the field as a filter.
>
> I've been meaning to make other subcommands aware of the new field as
> well, such as 'svn up', 'svn diff', 'svn log', but they haven't been
> really high priority. I could certainly finish those if people wanted
> me to.

The --targets option handles roughly half the features provided by
today's changelist implementation. How --targets is intended to be
used isn't perfectly clear, though:

$ svn help ci | grep 'targets arg '
  --targets arg : pass contents of file ARG as additional args

It would be nice if either --targets or changelist was implemented
consistently across commands, and if there was a more clear
distinction on when to use what, and what --targets was really
intended to do (since it sounds like you can use it to pass arbitary
arguments).

...
> * You say it "solves only the very most minor of use-cases that
> surround the scenario of working on multiple changesets in a
> single working copy at the same time." What are the major
> use-cases we're ignoring? I have the opposite impression, fwiw;
> in my experience, the current lightweight implementation solves
> 90% of the use-cases. (1) Looking at your list of patches, (2)
> Naming or destroying your patches, (3) Committing exactly one
> patch, and not another.
>
> (I don't consider overlapping changelists to be a common problem,
> and when it does happen, it almost always means that the patches
> *should* be developed in serial, not in parallel. So I don't
> think it's worthwhile to try to design a system that allows
> overlapping changelists to co-exist... to me, that's the 'minor'
> use-case.)

Because I often have the need for overlaping changelists, I don't find
the changelist feature as implemented today a meaningful enough
improvement over --targets. However, I would like to see it become
so!

While I agree that overlapping change sets *should* be developed
serially, my experience shows that in the majority of cases where I
have overlap, that the need for serial development is not apparent
soon enough in the development cycle to avoid the overlap. The
combination of the need for overlapping change sets and the frequency
which I find they occur tells me that we haven't solved 90% of the use
cases (I'd say more like 50%, between lack of support for overlapping
change sets, and lack of comprehensive changelist support across
sub-commands).

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.

You could (accurately) claim that I should've noticed this requirement
up front, noted the dependency, and implemented the changes in the
correct order. But let's be realistic here -- how often do you really
get perfect requirements?!

> * You say that you worry that the current implementation will make
> it hard to implement hunk-level management. Can you explain why?
> (Also, is this even a priority? I've never heard of users asking
> for that, or heard it discussed on any svn roadmap.)

I'm curious about this, too.