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

C. Michael Pilato wrote:

> came up, and my recollection was that we all pretty much agreed that, as
> written, it didn't actually solve any interesting problem that didn't
> already have a simple (albeit mildly annoying) workaround, and that the
> feature and its maintenance were, by and large, unjustifiable baggage.

I haven't looked at the implementation details in the source, so I don't
know how big that baggage really is.

But I agree that the feature doesn't solve big problems. In fact, I
think it will mostly lead to bad working practices:
IMHO it is better to commit often and not hold of a commit too long. And
that's exactly what will happen with this feature. People will start
working on a change, put those files into a changelist and postpone
committing it a long time. What they won't notice is that some other
change they made might also have changed one or more files they put into
such a changelist -> bad commit which breaks the build.

But maybe that implementation could be implemented in reverse?
Right now, you can commit all files belonging to a specific changeset.
How about having a 'blockset' instead of a changeset? The blockset would
always get filtered out from a commit (something like svn:ignored on
versioned files).

> My opinion is pretty easy to express: nice idea, but 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. And I'm
> concerned about the possibility of the existing feature getting in the
> way of what would *really* be useful, which is moving the granularity of
> a changelist from per-file to per-diff-hunk or per-line.

That would of course be a big and great feature. But not easy to implement.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org