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

Re: Svnant status tast limitations (?)

From: JP Fiset <jp_at_fiset.ca>
Date: 2005-09-21 15:34:23 CEST

Here is a link that explains how to count files in a fileset:
http://marc.theaimsgroup.com/?l=ant-user&m=111873202501736&w=2

Hope this helps,

JP

JP Fiset wrote:

> I believe the original intent of the svn-ant status task is to gather
> information about one item. In fact, for a given file, it returns the
> various status fields in properties. It is hard to imagine the
> expected behaviour of this task if it was to accept a file set.
>
> I have submitted a patch
> (http://subclipse.tigris.org/servlets/ReadMsg?list=dev&msgNo=1398)
> that implements file selectors for svn-ant (see
> http://subclipse.tigris.org/issues/show_bug.cgi?id=384). This is
> probably closer to what you want. Given a file set, the svn-ant
> selectors can discrimnate the files that have a given subversion
> status. Those file selectors can be used with conditional types such
> as <and/>, <or/> and <not/>. What you are left with is the task of
> verifying if the file set is empty. I do not know such a task of the
> top of my head, but you could easily write one or kludge <length/>
> into doing it.
>
> The only drawback to the file selectors, as I have submitted them, is
> that they can not detect missing and deleted files. This is because
> those files no longer exist on the file system, and therefore are not
> predicted by the internal file scanner. To do this, one would have to
> implement a 'svnFileSet', which would use the output of 'svn ls' as
> the basis of the scanning. A custom FileSet, such as that one, would
> be useful in that it would allow the discovery of missing/deleted
> files as well as ignoring all Subversion internal files (located in
> .svn directories). The only problem is that, as of ANT 1.6.x, there
> is no facility to create custom FileSet. Researching how likely it is
> feasible to create a custom fileset has led me to believe that it is
> not a good time to implement such a feature. ANT developers are
> currently working on allowing custom FileSet and are expecting that it
> will be available in ANT 1.7. However, it is such a big change
> (affect all fileset-based task), I do not yet understand how it will
> affect the ANT 'landscape'.
>
> If what you are looking for can work without detecting deleted and
> missing files, then the file selectors are the way to go. Otherwise,
> you might have to write your own task.
>
> JP
>
> Tejs Scharling wrote:
>
>> Greetings,
>>
>> I hope you can help me with the following problem.
>>
>> Using ANT in a release process, I need to check if my
>> Working Copy is in sync with the Working Base (i.e.
>> that I have updated and committed). The svnant status
>> task only supplies me with the status of a single
>> file/dir, and I need the status of the hole source
>> tree (a bit like the graphical indication the windows
>> tool TortoiseSVN gives me). Is there some way around
>> this problem?
>> If not, I can see that svnant uses the
>> ISVNClientAdapter.getSingleFileStatus() method to get
>> the status. Would it be possible to use the
>> ISVNClientAdapter.getStatus(<source tree>, recurse)
>> method and find the worst-case status of the returned
>> status array.
>>
>> / Tejs Scharling
>>
>>
>> Tejs Scharling
>> Rosensgade 18c, 3.tv.
>> 8000 Århus C
>>
>> tlf: 82507229
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
>> For additional commands, e-mail: users-help@subclipse.tigris.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
Received on Wed Sep 21 23:34:23 2005

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

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