> Well, yes, but tags and branches are really a kludge in svn.
> Personally I have moved to version control software beyond svn. ;-)
I have heard of such things but never seen one... there is usually
just a crater and some smoke by the time I am able to observe the
magic :D
> And, I thought from the obligation/advice discussion that you felt
> that semantics are important. ;-)
They are important, I am just trying to find out what is driving your
requirements.
> 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.
If I have a v1 compliant PDP I would want to test it against the v1
conformance tests. It doesn't seem logical that I would test it
against a portion of the v3 conformance tests. I am all for breaking
the test into core/profileA/profileB, but I disagree that we are not
maintaining versions of the tests since it is highly likely that there
may be revisions between XACML versions (making compliance test
version a useful bit of meta data ;)
b
>
>
> 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
>
>
> ---------------------------------------------------------------------
> 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