On 01/04/2013 04:54 PM, Stefan Sperling wrote:
> On Fri, Jan 04, 2013 at 04:25:07PM -0500, C. Michael Pilato wrote:
>> On 01/04/2013 03:57 PM, Daniel Shahaf wrote:
>>> Stefan Sperling wrote on Fri, Jan 04, 2013 at 19:31:20 +0100:
>>>> On Fri, Jan 04, 2013 at 01:23:28PM -0500, C. Michael Pilato wrote:
>>>>> Can anyone make an argument for me *not* to reintegrate my branch to trunk
>>>>> for 1.8 release? I need to code up some more regression tests for the --cl
>>>>> "" behaviors, but I don't really want to invest that energy today if I know
>>>>> that dev@ is disinterested in seeing this new functionality in 1.8 anyway.
>>>>
>>>> Please merge it to trunk!
>>>>
>>>> This feature is already mentioned in the 1.8 draft release notes and
>>>> I'm glad to learn that you've fixed it up.
>>>
>>> I hope that's not the only reason you want to merge it --- it'd be
>>> simple to axe it from the release notes.
>>
>> Yeah, I was kinda hoping for a bit more justification myself. Is the trunk
>> behavior what we want to ship/live with? See, I'm having a bit of trouble
>> really remembering the driving use-case here.
>
> Well, I was under the impression that there already was consensus
> that this was a good idea. You mentioned this feature had been discussed
> back in 2011, and it has existed on trunk for ages. So I didn't see any
> reason to question it.
>
> But if you're unsure about the design/implementation or the driving
> use cases, then yes, we should discuss these concerns. Could you be
> more specific about what exactly your concerns are?
My concern arises from the fact that, at the time the tracking issue was
filed, the goal was (as stated in the issue description) to "provide syntax
which means 'include all files *not* in a changelist'"
I cannot tell, from that context alone, if we said "files" because we meant
"files", or if we said "files" because we were being lazy and really meant
"files/dirs/symlinks/whatever".
If I tilt my head just right, I can sorta see an argument for an alternate
definition of: "provide syntax which means 'include all files and
directories *not* in a changelist'". But implementing as much -- and doing
it completely and correctly -- is a significant body of work that I'm not
interested in undertaking.
So, what I'm wondering is simple:
Have I on the branch (and based on the work Daniel started) met the original
criteria of this feature request, or is there more to be done either because
the feature request itself was short-sighted or because it was imprecisely
documented in the issue tracker?
Let me be clear, here: the changelist feature itself is of only marginal
value in my opinion, so I am hesitant to invest much energy "polishing a
turd". I'm quite comfortable with what's been done on the branch as an
incremental improvement over what sits in trunk, which is very easy to
describe to users even if it doesn't solve some particular use-case that
involves directories.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-01-04 23:12:59 CET