Re: [xacml] Conformance Tests

[Bill Parducci <bill@parducci.net>]

functionally tags and branches are the same thing in svn. if the  
semantics are an issue we can easily create/rename a directory  
structure called 'branches' rather than 'tags', but i am strongly  
opposed to creating static version names in the trunk. v1 is not a  
'component' of v2 if for no other reason than we cannot ensure 100%  
backwards compatibility in the specification in definitely.

further, this structure doesn't alleviate the "issue that spans  
version" user case. if there are multiple "live" instances of a test,  
the only solution is to replicate the changes (barring a merge).  
conversely, there are changes that may have unique results based upon  
version (e.g. deprecation of data type)

b

On Mar 9, 2009, at 7:00 AM, Erik Rissanen wrote:

> Hi Bill,
>
> I propose that we keep it like this:
>
> current/tests/v1
> current/tests/v2/core
> current/tests/v2/multiple
> current/tests/v3/core
> current/tests/v3/delegation
> current/tests/v3/multiple
> etc
>
> It is a convention in svn that you don't continue work on something  
> in the directory "tags". Tags are intended to be frozen in time. We  
> could make it a branch, but I think it is more appropriate to see  
> the whole thing as a set of "components", that is, tests for v1, v2,  
> v3, etc, which are all currently maintained (for instance if someone  
> reports a bug in the old tests), not branches.
>
> In general, tags are used to store a snapshot of an old state for  
> future reference. Branches are used when development of a single  
> item goes in multiple directions at the same time. I don't see the  
> need of either tags or branches in this case.
>
> Regards,
> Erik
>
> bill parducci wrote:
>> I don't understand where the "mixing of versions" comes from. As  
>> you can see in the current layout the v1 tests--as they are labeled  
>> in the doc--have been tagged/branched (svn doesn't differentiate  
>> really) and are wholly independent from the trunk ("/current").  
>> Work may continue on either independently (`svn switch` allows you  
>> to determine which branch/tag to work on).
>>
>> I understand the desire to break up the tests into functional  
>> groups but that it just that: a directory structure based upon  
>> categorization, not version. Since v1 has been in its current state  
>> for quite some time I suggest that this work be done on the current  
>> branch so as to only affect the work going formward.
>>
>> thanks
>>
>> b
>>
>> On Mar 9, 2009, at 1:19 AM, Erik Rissanen wrote:
>>
>>> Hi Bill,
>>>
>>> I was thinking that it's annoying to browse a flat structure with  
>>> hundreds of tests, mixed between different versions and features.  
>>> Note that I don't think we should ever throw away the 2.0 tests,  
>>> so it's not really a version control issue. It's about multiple  
>>> sets of files which will all be maintained. Tagging is not a good  
>>> solution for that.
>>>
>>> Regards,
>>> ERik
>>>
>>> Bill Parducci wrote:
>>>> I suggest we not attempt to circumvent the internal version  
>>>> control mechanism with static dirs :) How about we simply tag  
>>>> them? (We can branch the tests if we really think there will be a  
>>>> lot of work done on v2 tests after v3 tests are introduced).
>>>>
>>>> Sound workable?
>>>>
>>>> b
>>>>
>>>> On Mar 5, 2009, at 8:08 AM, Erik Rissanen wrote:
>>>>
>>>>> Thanks Bill,
>>>>>
>>>>> I will contribute more tests for 3.0 and the multiple resource  
>>>>> profiles.
>>>>>
>>>>> Could we perhaps make separate directories for v2.0 and v3.0?  
>>>>> And different profiles as well perhaps? It would make it easier  
>>>>> to find among them.
>>>>>
>>>>> Best regards,
>>>>> Erik
>>>>>
>>>>> bill parducci wrote:
>>>>>> I am checking in the conformance tests into subversion. I  
>>>>>> segmented the tests and schemas into separate directories for  
>>>>>> clarity. TC Members may check this out using Kavi auth using  
>>>>>> the following:
>>>>>>
>>>>>> svn co --username ##### --password ##### http://tools.oasis-open.org/version-control/svn/xacml/
>>>>>>
>>>>>> You can simply point your browser here if you would like to  
>>>>>> browse:
>>>>>>
>>>>>> http://tools.oasis-open.org/version-control/browse/wsvn/xacml/?rev=0&sc=0
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> b
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC  
>>>>>> that
>>>>>> generates this mail.  Follow this link to all your TCs in OASIS  
>>>>>> at:
>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this mail list, you must leave the OASIS TC  
>>>>> that
>>>>> generates this mail.  Follow this link to all your TCs in OASIS  
>>>>> at:
>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC  
>>>> that
>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/ 
>> my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php