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
> 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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jan 16 21:22:18 2007