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

Ben Collins-Sussman wrote:
> Mike, if you have real criticisms, I'd be happy to discuss them in
> detail. I need more elaboration from you, though.
>
> * 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.)

I think you're using "minor/major" to mean common/uncommon, where I was
using it to mean trivial/complex. I'm not claiming that the feature
doesn't do what it was intended to do. I merely expressed that there
are other ways to do it, and wondered aloud if the balance between the
convenience of having Subversion do it and the cost of maintaining the
design and implementation long-term had been properly struck.

From what I'm reading about the implementation, though, it seems pretty
simple, which lowers the bar for the utility the feature needs to
provide in order to be "worth it". As such, I'm not in opposition to
it. I'd forgotten, too, that eventually --changelist was code as a
filter, not a harvester, which is significantly less complicated and a
much cleaner UI.

> * 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.)

Don't assume that users voice every desire they might have for a piece
of software. But if it makes you feel better:

   I, Mike Pilato, user of Subversion, sure do wish Subversion could
   squirrel away and retrieve uncommitted changesets-in-progress with
   sub-file granularity so I could have changesets that overlap.

:-)

My concern about the existing feature complicating the one I actually
want follows strictly from the belief that it is extremely unlikely that
 UI added for your changelist feature will be sufficient to also cover
that advanced functionality. I'd feel better knowing that someone had
at least considered what such a UI might look like so we're less likely
to have to shim in additional, less natural command-line options later.
 Since you apparently weren't even thinking about the more advanced
feature, it seems unlikely that you can offer that peace of mind. But
then again, if we've no plans to go down that path in the future, it
hardly matters.

SIDEBAR: Claiming that changing the same file for different changesets
is a bad practice, but changing multiple files for different changesets
isn't, is a bit of a bogus argument that lives and dies on your
assumptions about the relationships between the lines of a file to one
another and of one file to another file. For example, tweaking the
parameter list for two functions whose implementations live in different
files, but whose prototypes happen to live in the same .h file, doesn't
mean those changes are *really* any more closely related than if their
prototypes lived in separate locations.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand