[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge svnraisetc branch to trunk

From: Blair Zajac <blair_at_orcaware.com>
Date: Thu, 07 May 2009 08:36:25 -0700

Hyrum K. Wright wrote:
> On May 7, 2009, at 8:38 AM, Stefan Sperling wrote:
>> On Thu, May 07, 2009 at 08:05:13AM -0500,
>> kmradke_at_rockwellcollins.com wrote:
>>> "Hyrum K. Wright" <hyrum_at_hyrumwright.org> wrote on 05/07/2009
>>> 07:22:17 AM:
>>>>> I am planning to merge 'svnraisetc' branch to trunk. This merge
>>>>> will
>>>>> add a tool
>>>>> "svnraisetreeconflict" to "contrib/client-side/
>>>>> svnraisetreeconflict"
>>>>> nothing
>>>>> more than that.
>>>>> For an explanation of what this tool does and other discussions,
>>>>> please have a
>>>>> look at this thread -
>>>>> http://subversion.tigris.org/ds/viewMessage.do?
>>>> dsForumId=462&dsMessageId=103756
>>>>> If anyone has any reservations on the above, please let me know.
>>>> Since contrib/ will be disappearing shortly, I'm a bit befuddled
>>>> as to
>>>> why this branch even exists at all? Either it should be made a part
>>>> of tools, with agreed-upon support from the Subversion community, or
>>>> I'd recommend hosting it somewhere else.
>>> I'm still a little concerned users will get the wrong impression
>>> when told "Thanks for the contrib, but go find somewhere else to
>>> put it."
>>> (I know I would have lost interest in helping...)
>> I was not under the impression that we would simply discard all of
>> contrib as it exists today, and be telling contributors to go away.
>> Rather, I though we'd audit contrib for things that have a license
>> which
>> allows distribution and which are useful and maintainable, and merge
>> all
>> of that stuff into tools/, and remove the rest.
>> That was my impression anyway. Is this correct?
> contrib/ can never just "go away". It's in the repo, we've got
> version control, and people can just use @37634 instead of the implied
> @HEAD when accessing it. We could 'svn rm ^/trunk/contrib' today, and
> then resurrect stuff as it get's audited.
>>> Therefore, I suggest creating a "Contrib manager" role that
>>> coordinates
>>> collecting these types of contributions into a common location
>>> (probably
>>> just another tigris project. e.g. svn-contrib)
>> Yes, we need someone to look through contrib, and make a summarised
>> list of what tools there are, what their licenses are, what their
>> purpose is, and possibly an estimate on each script's usefullness,
>> whether it serves its purpose well enough to be worth maintaining,
>> whether there already is an active maintainer for it, and whether
>> there are replacements we could point people at for useful things
>> that will go away. E.g. svn_load_dirs.pl could be replaced by svn-load
>> which already is an externally maintained script.
> Something like this would be useful, but not mandatory for removing
> contrib/ from HEAD.

I'm against removing contrib/ until we have a place to move it to and an
infrastructure to support it.

Kevin's idea of setting up svn-contrib is a good one. Just if it lives on
tigris or code.google.com is a question. I think I'd rather see it on Google Code.


Received on 2009-05-07 17:38:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.