[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Regarding issue #3348 ("Provide syntax which means 'include all files *not* in a changelist'")

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 4 Jan 2013 13:23:28 -0500

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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-01-04 19:24:05 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.