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

Re: svn:ignore with recursive and non-recursive patterns

From: Steve Cohen <scohen_at_javactivity.org>
Date: Thu, 02 Dec 2010 10:23:00 -0600

On 12/01/2010 12:29 PM, Steve Cohen wrote:
> I have a need to define a number of svn:ignore patterns in my project.
>
> Some are specific directories somewhere in my project tree. Others are
> particular file types created by a build process such as *.o which may
> be found in any number of directories.
>
> However, the svn propset command only allows the recursive -R switch to
> be applied to the entire set of values for the svn:ignore property.
> Whereas what is needed is to be able to apply the recursive switch to
> the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore). Is there any way of
> achieving this? There doesn't appear to be one. Yet without it,
> svn:ignore is useless, or at least too cumbersome to be used well.
>
> Steve Cohen
>
>
The following methodology seems to work pretty well in my case:

Check out the pristine source TWICE into two local working copies.

One one working copy perform the complete build.

Against that working copy run a python script based on os.walk that
looks for
a. executable files
b. other generated files of interest
c. newly created directories.

for each a or b found, use the python subprocess module to invoke svn
propget on the mirror of that directory in the second working copy.
This is necessary because, svn update and svn commit do not work on a
directory tree containing unversioned directories. Check to make sure
that the object is not already in the properties, and if not, add it to
the list and save it with svn propset.

for each c found do the same and then remove it from the dir list that
is recursed into by os.walk. Also remove any .svn directories from
os.walk without any processing.

Now there should be a clean copy of the project ignoring everything that
needs to be ignored.

I can't help but think there ought to be an easier way, but hey, job
security and all that.
Received on 2010-12-02 17:24:33 CET

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

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