Hi
Trying again.
I believe this bug is confirmed with the attached test case in my first
post. Can someone else please verify? (just to stop me from going insane)
Cheers / Erik
On Tue, Aug 30, 2011 at 10:11 AM, Erik Andersson <kirean_at_gmail.com> wrote:
> Can someone else please confirm the problem?
>
> Cheers / Erik
>
>
> On Thu, Aug 18, 2011 at 11:03 AM, Erik Andersson <kirean_at_gmail.com> wrote:
>
>> Hi Daniel and thank you for your quick response.
>>
>> I got sick at the time you responded and then I had to work with other
>> stuff before the vacations, but now I'm back on this.
>>
>> I now understand my misunderstandings on the attributes, but I'm still not
>> able to get it to work.
>>
>> I've attached a script which hopefully shows the problem.
>>
>> This is my results from the test:
>> <<< SNIP >>>
>> *** Running ant on build.xml to get revision.max-with-flags
>> Buildfile: /home/erik/sandbox/wc/build.xml
>>
>> getWcVersion:
>> [svn] Deprecated attribute 'javahl'. This attribute will disappear
>> with SVNANT 1.3.2. Use svnSetting instead.
>> [echo] 3M
>>
>> BUILD SUCCESSFUL
>> Total time: 1 second
>> *** Now running svn st show that we have no modifications
>> X goek
>>
>> Performing status on external item at 'goek'
>>
>> I still have "3M", although I have no modified files.
>>
>> Cheers / Erik
>>
>> On Thu, Jun 16, 2011 at 8:25 PM, Daniel Kasmeroglu <
>> daniel.kasmeroglu_at_kasisoft.net> wrote:
>>
>>> Hello Erik,
>>>
>>> First of all: Checkout the documentation ;-)
>>>
>>> Case 1:
>>> <svn>
>>> ...
>>> </svn>
>>>
>>> Case 2:
>>> <svn javahl="false">
>>> </svn>
>>>
>>> As mentioned within the documentation the attributes 'javahl' and
>>> 'svnkit' would look like this:
>>>
>>> Case 1: javahl=true, svnkit=false
>>> Case 2: javahl=false, svnkit=false
>>>
>>> This means Case 1 would try to make use of the JavaHL binding, so that's
>>> the reason for your error message regarding the missing binding (chapter
>>> 'Introduction' !).
>>> In Case 2 you disabled both: javahl and svnkit which means that it used
>>> the commandline adapter (the svn executables which were obviously on the
>>> path on your machine).
>>>
>>> A sidenote from myself: I don't like this way of specifying the backend
>>> client as it's unintuitive and misleading. I left it in version 1.3.1
>>> because the previous version was very old and I considered this a
>>> maintenance release (that's the reason for the deprecation messages). In
>>> future there will be only one attribute 'backend' with the values 'svnkit',
>>> 'javahl' and 'commandline'.
>>>
>>> Back to your problem: Apart from your misunderstanding related to the
>>> invocation I'm not sure why you think 'wcversion' isn't working correctly.
>>> Therefore I will give you a short description how I've verified it's
>>> functionality:
>>>
>>> * I've got a repository A with the maximum revision 481
>>> * I've got a repository B with the maximum revision 400
>>> * I've setup an 'svn:external' within a workingcopy of B to include 'A'
>>> (obviously I've also updated this workingcopy to include the content of A)
>>> * Calling 'wcversion' on the workingcopy delivers the revision number 400
>>> which is exactly the information that I would expect.
>>>
>>> If you're scenario is similar and it still doesn't seem to work, it would
>>> be nice if you could create a testcase in order to analyse the potential
>>> issue.
>>>
>>> Best regards
>>>
>>> Daniel Kasmeroglu
>>>
>>
>>
>
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2859795
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2011-10-21 07:52:14 CEST