On 1/16/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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.
Ah, yes, understood, and I agree. Every new feature has to strike
that balance, and as a developer community we've always been pretty
paranoid about evaluating things in that light. For that reason, I
designed the feature to be *very* simple in its implementation and
UI... so as to counterbalance the fact that it's solving a very
common, not-very-complicated problem. I don't want to swat a fly
with a Buick.
>
> 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.
Cool.
> 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.
>
> :-)
:-)
I agree it would be nice, but I feel like it would take months and
months to write such a feature, all to solve a use-case that's pretty
uncommon. I feel like it doesn't strike a good balance: tons of
work, not a whole lot of benefit. As I said before, if two
changesets-in-progress really affect the same file, it's also quite
likely that the changesets probably shouldn't be developed in parallel
anyway. So I guess on a personal level, I don't feel very strongly
about this itch.
>
> 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.
Perhaps we should ask the svk guys? Last I heard, svk actually has a
feature to manage patch-hunks for you. Or at least, when you merge
changes, it can interactively ask you questions about each hunk... I
wonder if it allows you to name sets of hunks, and commit specific
hunks as well?
>
> 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. [...]
Ah, I'm not saying that changing the same file for different
changesets is an inherently bad practice, just that it's *likely* to
be two changesets that are better off being developed in serial. I
agree that there are plenty of counterexamples; I'm only arguing that
they're not the norm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 16 22:47:40 2007