You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2013/01/04 19:23:28 UTC
Regarding issue #3348 ("Provide syntax which means 'include all files
*not* in a changelist'")
Take a minute to read up on the history of issue #3348:
http://subversion.tigris.org/issues/show_bug.cgi?id=3348
Okay. Thanks.
As you've read, this issue has had gone back and forth a little bit. It
took a while for us to settle on a UI approach that would work, but we
ultimately decided in Berlin in 2011 to let the empty-string changelist be
the trigger.
Daniel implemented a first pass at the feature, but the result wasn't
precisely a syntax which meant "include all files not in a changelist".
Rather, it was "include all files/dirs/etc. not in a changelist". He didn't
quite get around to finishing off that approach, and in process of trying to
do so for him, I noticed that including directories in the result set caused
some really wonky behavior. Long story short, we pulled the feature from
trunk, and then I went off on a branch and reimplemented it to only include
files (or non-dirs, I guess ... symlinks count as files in this context).
To my knowledge, the branch code behaves in a manner that is consistent from
subcommand to subcommand, and consistent with the general principles of
changelist filtering (which is that if changelist filtering is in place,
directories are summarily ignored).
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/04/2013 04:25 PM, 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.
Oops! Sorry -- I meant "Is the *branch* behavior..." here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include
all files *not* in a changelist'")
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Fri, Jan 04, 2013 at 22:54:47 +0100:
> 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?
I'm not sure there is strong demand for this feature and elsethread it's
pretty obvious the design isn't set in stone yet.
Personally I vote for leaving trunk as-is (with no trace of the feature)
and punting reimplementing it --- or merging cmpilato's reimplementation
--- to 1.9-consider.
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by Stefan Sperling <st...@apache.org>.
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?
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/04/2013 04:26 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Fri, Jan 04, 2013 at 16:25:07 -0500:
>> 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.
>
> svn st -q --cl ""
>
> ?
I suppose. Seems kinda lame, though, since 'svn status -q' always shows you
the non-changelist stuff at the top of its output anyway.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include
all files *not* in a changelist'")
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Sat, Jan 05, 2013 at 22:22:20 -0500:
> On 01/04/2013 05:44 PM, Stefan Sperling wrote:
> > On Fri, Jan 04, 2013 at 05:29:30PM -0500, C. Michael Pilato wrote:
> >> "--cl=none" -- introduces a reserved changelist name "none" that
> >> someone, somewhere might already be really using.
> >
> > Is this really a problem?
> >
> > We're bumping the working copy format anyway for 1.8, so the new
> > format could start reserving the 'none' changelist. An existing 'none'
> > changelist could be detected by 'svn upgrade'. It could then ask the user
> > to rename the changelist before upgrading, or even prompt for a new
> > name which makes upgrading easier if 1.7 isn't installed anymore.
> >
> > I like --cl none much better than --cl "".
>
> Oooh... that's a sneaky idea. I rather like it! Doesn't really hope folks
> who have scripted processes which involve a changelist named "none", of
> course, but we may be well into "edge-case" territory, here.
--cl=svn:none would be even more edge-case.
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/04/2013 05:44 PM, Stefan Sperling wrote:
> On Fri, Jan 04, 2013 at 05:29:30PM -0500, C. Michael Pilato wrote:
>> "--cl=none" -- introduces a reserved changelist name "none" that
>> someone, somewhere might already be really using.
>
> Is this really a problem?
>
> We're bumping the working copy format anyway for 1.8, so the new
> format could start reserving the 'none' changelist. An existing 'none'
> changelist could be detected by 'svn upgrade'. It could then ask the user
> to rename the changelist before upgrading, or even prompt for a new
> name which makes upgrading easier if 1.7 isn't installed anymore.
>
> I like --cl none much better than --cl "".
Oooh... that's a sneaky idea. I rather like it! Doesn't really hope folks
who have scripted processes which involve a changelist named "none", of
course, but we may be well into "edge-case" territory, here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by Branko Čibej <br...@wandisco.com>.
On 04.01.2013 23:44, Stefan Sperling wrote:
> On Fri, Jan 04, 2013 at 05:29:30PM -0500, C. Michael Pilato wrote:
>> "--cl=none" -- introduces a reserved changelist name "none" that
>> someone, somewhere might already be really using.
> Is this really a problem?
>
> We're bumping the working copy format anyway for 1.8, so the new
> format could start reserving the 'none' changelist. An existing 'none'
> changelist could be detected by 'svn upgrade'. It could then ask the user
> to rename the changelist before upgrading, or even prompt for a new
> name which makes upgrading easier if 1.7 isn't installed anymore.
>
> I like --cl none much better than --cl "".
I find it more aesthetically pleasing a well. I have no opinion on
changelists, having never used them.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by Stefan Sperling <st...@apache.org>.
On Fri, Jan 04, 2013 at 05:29:30PM -0500, C. Michael Pilato wrote:
> "--cl=none" -- introduces a reserved changelist name "none" that
> someone, somewhere might already be really using.
Is this really a problem?
We're bumping the working copy format anyway for 1.8, so the new
format could start reserving the 'none' changelist. An existing 'none'
changelist could be detected by 'svn upgrade'. It could then ask the user
to rename the changelist before upgrading, or even prompt for a new
name which makes upgrading easier if 1.7 isn't installed anymore.
I like --cl none much better than --cl "".
RE: Regarding issue #3348 ("Provide syntax which means 'include all files *not* in a changelist'")
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: vrijdag 4 januari 2013 23:30
> To: Julian Foad
> Cc: Daniel Shahaf; Subversion Development
> Subject: Re: Regarding issue #3348 ("Provide syntax which means 'include all
> files *not* in a changelist'")
>
> On 01/04/2013 05:10 PM, Julian Foad wrote:
> > On the other hand it does have some uses ("show me all the local mods
> > that I haven't assigned to any changelist", "assign them all to a named
> > changelist now"), and I consider the whole changelists feature to be a
> > very marginal bit of functionality so it doesn't matter much either way,
> > and it doesn't seem at all burdonsome to maintain.
>
> "Marginal" ... same word I used elsethread. :-)
>
> > I think using "--cl=''" for the UI is lame and driven by just letting the
> > UI be dictated by the implementation.
>
> I know what you're saying, and you may be right about how we originally
> arrived at this UI. I do recall that we considered the very things you
> suggested, but didn't stick with them for various reasons:
>
> "--cl=none" -- introduces a reserved changelist name "none" that
> someone, somewhere might already be really using.
>
> "--no-changelist" -- implies that directories are included.
>
> In a way, the current UI -- as ugly as it may seem -- turns out to actually
> align pretty well with the real behaviors of the feature: the very presence
> of the --cl option at all always indicates that the subcommand's operation
> will be limited to things that can be assigned to changelists (files only),
> and the empty-string argument says "... and of those files, recognize only
> the ones with no changelist".
>
> If we decide instead that what is desired is a way to say "all files *and
> directories* not in a changelist", then I agree: --cl="" is bust, and
> something like --without-changelist (--wo-cl?) makes more sense.
I think that one of the major problems is that mixing our depth handling and changelists doesn't work.
Currently commands only work 'as expected' with depth infinity and a changelist filter, and then for directories the depth infinity has side effects.
In most cases changelists for directories *would* work, if that makes the client pass the changelist-selected targets to the library, but then with depth empty.
E.g. since 1.7 you can 'svn ci --depth empty DIR' a directory copy, but using changelists would require a depth infinity walk to find the targets.
In AnkhSVN and TortoiseSVN the changelist is processed one level higher up in the client UI, and here allowing to store a changelist for directories makes sense.
So maybe we should split the depth for the target walk (filling the target list), from the operation depth for the relevant commands (maybe always depth empty?) for changelist mode?
Bert
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/04/2013 05:10 PM, Julian Foad wrote:
> On the other hand it does have some uses ("show me all the local mods
> that I haven't assigned to any changelist", "assign them all to a named
> changelist now"), and I consider the whole changelists feature to be a
> very marginal bit of functionality so it doesn't matter much either way,
> and it doesn't seem at all burdonsome to maintain.
"Marginal" ... same word I used elsethread. :-)
> I think using "--cl=''" for the UI is lame and driven by just letting the
> UI be dictated by the implementation.
I know what you're saying, and you may be right about how we originally
arrived at this UI. I do recall that we considered the very things you
suggested, but didn't stick with them for various reasons:
"--cl=none" -- introduces a reserved changelist name "none" that
someone, somewhere might already be really using.
"--no-changelist" -- implies that directories are included.
In a way, the current UI -- as ugly as it may seem -- turns out to actually
align pretty well with the real behaviors of the feature: the very presence
of the --cl option at all always indicates that the subcommand's operation
will be limited to things that can be assigned to changelists (files only),
and the empty-string argument says "... and of those files, recognize only
the ones with no changelist".
If we decide instead that what is desired is a way to say "all files *and
directories* not in a changelist", then I agree: --cl="" is bust, and
something like --without-changelist (--wo-cl?) makes more sense.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include all files *not* in a changelist'")
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> C. Michael Pilato wrote on Fri, Jan 04, 2013 at 16:25:07 -0500:
>> >> 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.
>>
>> 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.
>
> svn st -q --cl ""
>
> ?
I think the need for this feature is not very strong, more like an enhancement that should be one of a set of enhancements to
changelists than something we would plan to introduce by itself into a
1.x release if we were planning what to deliver.
On the other hand it does have some uses ("show me all the local mods that I haven't
assigned to any changelist", "assign them all to a named changelist
now"), and I consider the whole changelists feature to be a very marginal bit of functionality so it doesn't matter much either way, and it doesn't seem at all burdonsome to maintain.
I think using "--cl=''" for the UI is lame and driven by just letting the UI be dictated by the implementation. What if we later add an option for selecting the files in *any* named changelist, for example? We could say that "--cl=''" is a fair choice of UI for that meaning also.
Surely the UI should be something like
--no-cl | --no-changelist
or
--cl=none
(which would be a reserved word -- yes I know that's not fantastic either).
Then if we later add an option such as "in any named changelist" that could be
--any-cl | --any-changelist
and then there wont be the archaic "--cl=''" hanging around as an embarrassing backward-compatibility alias for "uh... which one did it used to mean back in the 1.8 days?"
So -0.5 from me on putting this UI in 1.8 and +0 from me on putting this *feature* in 1.8.
If you all want to just put it out there as it is and not care about the UI, fair enough.
- Julian
Re: Regarding issue #3348 ("Provide syntax which means 'include
all files *not* in a changelist'")
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Fri, Jan 04, 2013 at 16:25:07 -0500:
> 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.
svn st -q --cl ""
?
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Regarding issue #3348 ("Provide syntax which means 'include
all files *not* in a changelist'")
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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.
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by Stefan Sperling <st...@apache.org>.
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.
Re: Regarding issue #3348 ("Provide syntax which means 'include all
files *not* in a changelist'")
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/04/2013 01:23 PM, C. Michael Pilato wrote:
> Take a minute to read up on the history of issue #3348:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3348
>
> Okay. Thanks.
Consensus on this list was not so much consensus as a general uneasiness
about moving forward on this issue at all. So I've documented what my
branch holds, pointed to this thread from the issue, and booted the issue
into 1.9-consider.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development