[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Conformance Tests
Well, yes, but tags and branches are really a kludge in svn. Personally
I have moved to version control software beyond svn. ;-)
And, I thought from the obligation/advice discussion that you felt that
semantics are important. ;-)
I do think that v1 is a component. It's a component of the conformance
test package. It's not a version of the conformance test package. Though
it is a version of XACML, it's not XACML we are versioning here.
But anyway, I could live with your suggested approach.
Regards,
Erik
Bill Parducci wrote:
> 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
>
>
> ---------------------------------------------------------------------
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]