You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan <lu...@gmx.de> on 2018/04/04 21:12:11 UTC
move certain svn props to top level path?
Hi,
atm we specify the following svn properties on trunk:
* bugtraq:url
* bugtraq:logregexp
* tsvn:logwidthmarker
* tsvn:projectlanguage
* webviewer:revision
* (possibly by the time you read this, I added webviewer:pathrevision)
Since these properties are currently not set project wide but rather on
each branch/tags we now have branches still pointing to the old
bugtrag:url (f.e. the 1.9.x branch) and some branches not having certain
properties at all (f.e. the 1.7.x branch missing the webviewer:revision
property).
I'd therefore like to suggest that we specify these properties just once
at the top level (i.e. on https://svn.apache.org/repos/asf/subversion)
and remove them on the sub-nodes (i.e. trunk, branches/xxx, tags/xxx,
etc.). This will ensure we have a consistent setting for these project wise.
Thoughts?
Regards,
Stefan
Re: move certain svn props to top level path?
Posted by Stefan <lu...@posteo.de>.
On 16/04/2018 09:15, Julian Foad wrote:
> Branko Čibej wrote:
>> On 15.04.2018 23:42, Stefan wrote:
>>> On 15/04/2018 22:56, Julian Foad wrote: [...]
>
>>>> - If the properties are not set for a folder, the client should
>>>> search upwards
>>>> in the working copy for them until the working copy root is
>>>> reached.
>
>>> I'll check with Stefan to make things either made more clear or
>>> removed (if outdated meanwhile, which to me this phrase looks like) in
>>> the docu.
>
> I agree it looks like that doc is simply out of date.
FTR: StefanK clarified it in the docs now by adding the following note
to that paragraph:
Note: as of svn 1.8, properties are automatically inherited so searching up
the working copy is not necessary anymore.
[...]
Regards,
Stefan
Re: move certain svn props to top level path?
Posted by Stefan <lu...@posteo.de>.
On 16/04/2018 09:15, Julian Foad wrote:
>>>>> Tags should not change.
>>>>> +1 for removing those properties from branches.
>>>> That part I agree with.
>>>
>>> I'm not going to make a case out of this, but please be aware the
>>> implications of keeping the incorrect/outdated props on the tags:
>
> I recognize that it's an inconvenience, yes, but note the same problem
> with tags exists in other forms -- e.g. there are hundreds of code
> comments pointing to the old issue tracker and mailing list URLs. The
> way I see it, we would not expect to modify tags to resolve those
> kinds of problem, just expect the reader to beware of such issues when
> working with old data, and so I feel we should apply that reasoning
> consistently even though it would be technically easy to modify the data.
all redundant SVN props removed from all branches in r1829788
FTR: Personally I see quite a difference between modifying/correcting
project-wide SVN properties and modifying content/properties which one
would consider being an inherent (logical) part of a tag. But I
obviously this is not a non-controversial matter so I'm certainly fine
with leaving this for tags as they are, of course. :-)
Regards,
Stefan
Re: move certain svn props to top level path?
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote:
> On 15.04.2018 23:42, Stefan wrote:
>> On 15/04/2018 22:56, Julian Foad wrote:
>>> Mark's blog post there says the spec was developed jointly with Subclipse so that's at least one other.
>>>
>>> Did you (Stefan) check inheritance works as expected?
>> I know for sure that it's working for TSVN (that's the way I set
>> things up at our company). I don't have Subclipse available however,
>> so can't check it there.
OK, that's good enough for me.
>>> - If the properties are not set for a folder, the client should search upwards
>>> in the working copy for them until the working copy root is reached.
>> I'll check with Stefan to make things either made more clear or
>> removed (if outdated meanwhile, which to me this phrase looks like) in
>> the docu.
I agree it looks like that doc is simply out of date.
>> Note that the actual user documentation is usually more
>> up-to-date and with regards to the property handling also states: "As
>> of version 1.8, TortoiseSVN and Subversion use so called |inherited
>> properties|, [...]
Perfect!
>>> If I have misunderstood something, then the Subversion feature "Inheritable properties" may possibly have made this "Just work", possibly; but I don't think so; but at least that feature should make it much easier to implement inheritance that searches up beyond the WC root to a folder that's only in the repository, if/when the various clients choose to do so.
Looks like TortoiseSVN at least was updated in that way; other clients
likely were updated too if anybody cared about them.
Good enough for me.
Please go ahead!
>>>> Tags should not change.
>>>> +1 for removing those properties from branches.
>>> That part I agree with.
>>
>> I'm not going to make a case out of this, but please be aware the
>> implications of keeping the incorrect/outdated props on the tags:
I recognize that it's an inconvenience, yes, but note the same problem
with tags exists in other forms -- e.g. there are hundreds of code
comments pointing to the old issue tracker and mailing list URLs. The
way I see it, we would not expect to modify tags to resolve those kinds
of problem, just expect the reader to beware of such issues when working
with old data, and so I feel we should apply that reasoning consistently
even though it would be technically easy to modify the data.
- Julian
Re: move certain svn props to top level path?
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 23:42, Stefan wrote:
> On 15/04/2018 22:56, Julian Foad wrote:
>> Branko Čibej wrote on 2018-04-15:
>>> On 15.04.2018 21:01, Stefan wrote:
>>>> On 05/04/2018 00:09, Stefan wrote:
>>>>> I'm not sure if there are other tools around using these. I'm talking
>>>>> here TSVN which utilizes all of these properties and yes, it's treating
>>>>> them as inheritable ones. There seem to be other tools using these as
>>>>> well [1/2], though I can't say for sure whether they are treating them
>>>>> as inheritable (though I'd strongly suspect so).
>>>>> https://markphip.blogspot.de/2007/01/integrating-subversion-with-your-issue.html
>> Mark's blog post there says the spec was developed jointly with Subclipse so that's at least one other.
>>
>> Did you (Stefan) check inheritance works as expected?
> I know for sure that it's working for TSVN (that's the way I set
> things up at our company). I don't have Subclipse available however,
> so can't check it there.
>> The spec at
>>
>> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt
>>
>> (give the username 'guest' and no password to access it) says:
>>
>> - If the properties are not set for a folder, the client should search upwards
>> in the working copy for them until the working copy root is reached.
>>
>> It doesn't say the client will search up into a parent folder in the repository that isn't in the WC.
>>
>> That suggests your change may break quite a lot of use cases unless the info I found above is out of date.
> I'll check with Stefan to make things either made more clear or
> removed (if outdated meanwhile, which to me this phrase looks like) in
> the docu. Note that the actual user documentation is usually more
> up-to-date and with regards to the property handling also states: "As
> of version 1.8, TortoiseSVN and Subversion use so called |inherited
> properties|, which means a property that is set on a folder is
> automatically also implicitly set on all subfolders. So there's no
> need to set the properties on all folders anymore but only on the root
> folder." [1]
> While this is not 100% clear here that "folder" in this regards is no
> longer limited to the WC checkout root, this is actually what is meant
> here, as far as I'm aware.
>
> And just to be 101% sure: I just double checked with current SVN trunk
> where the props were already removed. TSVN works there as expected.
> All the properties I moved to the subversion root are listed as
> inherited props.
>> If I have misunderstood something, then the Subversion feature "Inheritable properties" may possibly have made this "Just work", possibly; but I don't think so; but at least that feature should make it much easier to implement inheritance that searches up beyond the WC root to a folder that's only in the repository, if/when the various clients choose to do so.
>>
>>> Tags should not change.
>>> +1 for removing those properties from branches.
>> That part I agree with.
>>
>> - Julian
> I'm not going to make a case out of this, but please be aware the
> implications of keeping the incorrect/outdated props on the tags:
> - checkout the 1.9.0 tag
> - bring up the TSVN log dialog of the WC
> - select r1689313 (which has a reference to issue 4582 f.e.)
> - click the linked issue -> brings up the old tigris issue tracker
> instead of the JIRA one:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4582
> - right click an entry in the TSVN log dialog -> select "View revision
> in webviewer" -> brings up the http-link (instead of the https-link -
> while "View revision for path in webviewer" leads to the https-URL)
Note that if a user wants to dig in to solved issues, they can get the
same info from release branches as from release tags. And since we all
agree about removing the properties from branches, inheritance will work
as expected. New release tags will not have those properties, either.
-- Brane
Re: move certain svn props to top level path?
Posted by Stefan <lu...@posteo.de>.
On 15/04/2018 22:56, Julian Foad wrote:
> Branko Čibej wrote on 2018-04-15:
>> On 15.04.2018 21:01, Stefan wrote:
>>> On 05/04/2018 00:09, Stefan wrote:
>>>> I'm not sure if there are other tools around using these. I'm talking
>>>> here TSVN which utilizes all of these properties and yes, it's treating
>>>> them as inheritable ones. There seem to be other tools using these as
>>>> well [1/2], though I can't say for sure whether they are treating them
>>>> as inheritable (though I'd strongly suspect so).
>>>> https://markphip.blogspot.de/2007/01/integrating-subversion-with-your-issue.html
> Mark's blog post there says the spec was developed jointly with Subclipse so that's at least one other.
>
> Did you (Stefan) check inheritance works as expected?
I know for sure that it's working for TSVN (that's the way I set things
up at our company). I don't have Subclipse available however, so can't
check it there.
>
> The spec at
>
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt
>
> (give the username 'guest' and no password to access it) says:
>
> - If the properties are not set for a folder, the client should search upwards
> in the working copy for them until the working copy root is reached.
>
> It doesn't say the client will search up into a parent folder in the repository that isn't in the WC.
>
> That suggests your change may break quite a lot of use cases unless the info I found above is out of date.
I'll check with Stefan to make things either made more clear or removed
(if outdated meanwhile, which to me this phrase looks like) in the docu.
Note that the actual user documentation is usually more up-to-date and
with regards to the property handling also states: "As of version 1.8,
TortoiseSVN and Subversion use so called |inherited properties|, which
means a property that is set on a folder is automatically also
implicitly set on all subfolders. So there's no need to set the
properties on all folders anymore but only on the root folder." [1]
While this is not 100% clear here that "folder" in this regards is no
longer limited to the WC checkout root, this is actually what is meant
here, as far as I'm aware.
And just to be 101% sure: I just double checked with current SVN trunk
where the props were already removed. TSVN works there as expected. All
the properties I moved to the subversion root are listed as inherited props.
>
> If I have misunderstood something, then the Subversion feature "Inheritable properties" may possibly have made this "Just work", possibly; but I don't think so; but at least that feature should make it much easier to implement inheritance that searches up beyond the WC root to a folder that's only in the repository, if/when the various clients choose to do so.
>
>> Tags should not change.
>> +1 for removing those properties from branches.
> That part I agree with.
>
> - Julian
I'm not going to make a case out of this, but please be aware the
implications of keeping the incorrect/outdated props on the tags:
- checkout the 1.9.0 tag
- bring up the TSVN log dialog of the WC
- select r1689313 (which has a reference to issue 4582 f.e.)
- click the linked issue -> brings up the old tigris issue tracker
instead of the JIRA one:
http://subversion.tigris.org/issues/show_bug.cgi?id=4582
- right click an entry in the TSVN log dialog -> select "View revision
in webviewer" -> brings up the http-link (instead of the https-link -
while "View revision for path in webviewer" leads to the https-URL)
Regards,
Stefan
[1]
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html
Re: move certain svn props to top level path?
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote on 2018-04-15:
> On 15.04.2018 21:01, Stefan wrote:
> > On 05/04/2018 00:09, Stefan wrote:
> >> I'm not sure if there are other tools around using these. I'm talking
> >> here TSVN which utilizes all of these properties and yes, it's treating
> >> them as inheritable ones. There seem to be other tools using these as
> >> well [1/2], though I can't say for sure whether they are treating them
> >> as inheritable (though I'd strongly suspect so).
> >> https://markphip.blogspot.de/2007/01/integrating-subversion-with-your-issue.html
Mark's blog post there says the spec was developed jointly with Subclipse so that's at least one other.
Did you (Stefan) check inheritance works as expected?
The spec at
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt
(give the username 'guest' and no password to access it) says:
- If the properties are not set for a folder, the client should search upwards
in the working copy for them until the working copy root is reached.
It doesn't say the client will search up into a parent folder in the repository that isn't in the WC.
That suggests your change may break quite a lot of use cases unless the info I found above is out of date.
If I have misunderstood something, then the Subversion feature "Inheritable properties" may possibly have made this "Just work", possibly; but I don't think so; but at least that feature should make it much easier to implement inheritance that searches up beyond the WC root to a folder that's only in the repository, if/when the various clients choose to do so.
> Tags should not change.
> +1 for removing those properties from branches.
That part I agree with.
- Julian
Re: move certain svn props to top level path?
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 21:01, Stefan wrote:
> On 05/04/2018 00:09, Stefan wrote:
>> On 04/04/2018 23:47, Branko Čibej wrote:
>>> On 04.04.2018 23:12, Stefan wrote:
>>>> Hi,
>>>>
>>>> atm we specify the following svn properties on trunk:
>>>>
>>>> * bugtraq:url
>>>> * bugtraq:logregexp
>>>> * tsvn:logwidthmarker
>>>> * tsvn:projectlanguage
>>>> * webviewer:revision
>>>> * (possibly by the time you read this, I added webviewer:pathrevision)
>>>>
>>>> Since these properties are currently not set project wide but rather
>>>> on each branch/tags we now have branches still pointing to the old
>>>> bugtrag:url (f.e. the 1.9.x branch) and some branches not having
>>>> certain properties at all (f.e. the 1.7.x branch missing the
>>>> webviewer:revision property).
>>>>
>>>> I'd therefore like to suggest that we specify these properties just
>>>> once at the top level (i.e. on
>>>> https://svn.apache.org/repos/asf/subversion) and remove them on the
>>>> sub-nodes (i.e. trunk, branches/xxx, tags/xxx, etc.). This will ensure
>>>> we have a consistent setting for these project wise.
>>>>
>>>> Thoughts?
>>>>
>>> I don't even know what these properties are, nor why they're set on our
>>> trunk directory. Assuming they're used by some tools that I'm unaware of
>>> (ok ... I can probably guess what the tsvn: ones are for), you can only
>>> move them a level up if these tools treat them as inheritable properties.
>>>
>>> -- Brane
>> I'm not sure if there are other tools around using these. I'm talking
>> here TSVN which utilizes all of these properties and yes, it's treating
>> them as inheritable ones. There seem to be other tools using these as
>> well [1/2], though I can't say for sure whether they are treating them
>> as inheritable (though I'd strongly suspect so).
>>
>> [1]
>> https://stackoverflow.com/questions/47846726/how-to-work-with-svn-propertiesbugtraqlogregex
>> [2]
>> https://markphip.blogspot.de/2007/01/integrating-subversion-with-your-issue.html
> The properties were added to subversion root in r1829215-r1829221 and
> dropped from trunk in r1829223.
>
> I was actually about to remove the properties in a single commit from
> all branches as well as from all tags but am unsure about whether this
> would be acceptable especially for the branches (given the usual
> STATUS-nomination workflow). Would anybody object to me removing the
> redundant SVN props from all tags and branches in a single commit (with
> the commit log message then only stating:
> ".: Removed redundant SVN properties"
> (i.e. without explicitly listing all branches/tags which would be quite
> a bunch of entries otherwise).
Tags should not change.
+1 for removing those properties from branches.
-- Brane
Re: move certain svn props to top level path?
Posted by Stefan <lu...@posteo.de>.
On 05/04/2018 00:09, Stefan wrote:
> On 04/04/2018 23:47, Branko Čibej wrote:
>> On 04.04.2018 23:12, Stefan wrote:
>>> Hi,
>>>
>>> atm we specify the following svn properties on trunk:
>>>
>>> * bugtraq:url
>>> * bugtraq:logregexp
>>> * tsvn:logwidthmarker
>>> * tsvn:projectlanguage
>>> * webviewer:revision
>>> * (possibly by the time you read this, I added webviewer:pathrevision)
>>>
>>> Since these properties are currently not set project wide but rather
>>> on each branch/tags we now have branches still pointing to the old
>>> bugtrag:url (f.e. the 1.9.x branch) and some branches not having
>>> certain properties at all (f.e. the 1.7.x branch missing the
>>> webviewer:revision property).
>>>
>>> I'd therefore like to suggest that we specify these properties just
>>> once at the top level (i.e. on
>>> https://svn.apache.org/repos/asf/subversion) and remove them on the
>>> sub-nodes (i.e. trunk, branches/xxx, tags/xxx, etc.). This will ensure
>>> we have a consistent setting for these project wise.
>>>
>>> Thoughts?
>>>
>> I don't even know what these properties are, nor why they're set on our
>> trunk directory. Assuming they're used by some tools that I'm unaware of
>> (ok ... I can probably guess what the tsvn: ones are for), you can only
>> move them a level up if these tools treat them as inheritable properties.
>>
>> -- Brane
> I'm not sure if there are other tools around using these. I'm talking
> here TSVN which utilizes all of these properties and yes, it's treating
> them as inheritable ones. There seem to be other tools using these as
> well [1/2], though I can't say for sure whether they are treating them
> as inheritable (though I'd strongly suspect so).
>
> [1]
> https://stackoverflow.com/questions/47846726/how-to-work-with-svn-propertiesbugtraqlogregex
> [2]
> https://markphip.blogspot.de/2007/01/integrating-subversion-with-your-issue.html
The properties were added to subversion root in r1829215-r1829221 and
dropped from trunk in r1829223.
I was actually about to remove the properties in a single commit from
all branches as well as from all tags but am unsure about whether this
would be acceptable especially for the branches (given the usual
STATUS-nomination workflow). Would anybody object to me removing the
redundant SVN props from all tags and branches in a single commit (with
the commit log message then only stating:
".: Removed redundant SVN properties"
(i.e. without explicitly listing all branches/tags which would be quite
a bunch of entries otherwise).
Regards,
Stefan
Re: move certain svn props to top level path?
Posted by Stefan <lu...@posteo.de>.
On 04/04/2018 23:47, Branko Čibej wrote:
> On 04.04.2018 23:12, Stefan wrote:
>> Hi,
>>
>> atm we specify the following svn properties on trunk:
>>
>> * bugtraq:url
>> * bugtraq:logregexp
>> * tsvn:logwidthmarker
>> * tsvn:projectlanguage
>> * webviewer:revision
>> * (possibly by the time you read this, I added webviewer:pathrevision)
>>
>> Since these properties are currently not set project wide but rather
>> on each branch/tags we now have branches still pointing to the old
>> bugtrag:url (f.e. the 1.9.x branch) and some branches not having
>> certain properties at all (f.e. the 1.7.x branch missing the
>> webviewer:revision property).
>>
>> I'd therefore like to suggest that we specify these properties just
>> once at the top level (i.e. on
>> https://svn.apache.org/repos/asf/subversion) and remove them on the
>> sub-nodes (i.e. trunk, branches/xxx, tags/xxx, etc.). This will ensure
>> we have a consistent setting for these project wise.
>>
>> Thoughts?
>>
>
> I don't even know what these properties are, nor why they're set on our
> trunk directory. Assuming they're used by some tools that I'm unaware of
> (ok ... I can probably guess what the tsvn: ones are for), you can only
> move them a level up if these tools treat them as inheritable properties.
>
> -- Brane
I'm not sure if there are other tools around using these. I'm talking
here TSVN which utilizes all of these properties and yes, it's treating
them as inheritable ones. There seem to be other tools using these as
well [1/2], though I can't say for sure whether they are treating them
as inheritable (though I'd strongly suspect so).
[1]
https://stackoverflow.com/questions/47846726/how-to-work-with-svn-propertiesbugtraqlogregex
[2]
https://markphip.blogspot.de/2007/01/integrating-subversion-with-your-issue.html
Regards,
Stefan
Re: move certain svn props to top level path?
Posted by Branko Čibej <br...@apache.org>.
On 04.04.2018 23:12, Stefan wrote:
>
> Hi,
>
> atm we specify the following svn properties on trunk:
>
> * bugtraq:url
> * bugtraq:logregexp
> * tsvn:logwidthmarker
> * tsvn:projectlanguage
> * webviewer:revision
> * (possibly by the time you read this, I added webviewer:pathrevision)
>
> Since these properties are currently not set project wide but rather
> on each branch/tags we now have branches still pointing to the old
> bugtrag:url (f.e. the 1.9.x branch) and some branches not having
> certain properties at all (f.e. the 1.7.x branch missing the
> webviewer:revision property).
>
> I'd therefore like to suggest that we specify these properties just
> once at the top level (i.e. on
> https://svn.apache.org/repos/asf/subversion) and remove them on the
> sub-nodes (i.e. trunk, branches/xxx, tags/xxx, etc.). This will ensure
> we have a consistent setting for these project wise.
>
> Thoughts?
>
I don't even know what these properties are, nor why they're set on our
trunk directory. Assuming they're used by some tools that I'm unaware of
(ok ... I can probably guess what the tsvn: ones are for), you can only
move them a level up if these tools treat them as inheritable properties.
-- Brane