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

Re: Pending commits, anyone ever thought about this feature?

From: Andrés G. Aragoneses <knocte_at_gmail.com>
Date: Thu, 03 Jul 2008 22:56:04 +0200

Reedick, Andrew wrote:
>
>> -----Original Message-----
>> From: John Peacock [mailto:john.peacock_at_havurah-software.org]
>> Sent: Wednesday, July 02, 2008 2:54 PM
>> To: "Andrés G. Aragoneses"
>> Cc: users_at_subversion.tigris.org
>> Subject: Re: Pending commits, anyone ever thought about this feature?
>
>> I seriously doubt that this feature would be accepted in the core code.
>> It would implement a workflow that seems ways too narrowly defined
>> for
>> a general purpose tool like Subversion.
>
>> imagine a web app that automatically hands out novice commit ID's and
>> precreates a branch for them and updates the security stanza.
>> Maintainers would simply be set up to have rights to the main project
>> and get commit e-mails for anything under their purview...
>>
>
>
> Any decent bug/ticket/issue tracking system should be able to fire a trigger/hook/event script to precreate the branch, set auth permissions on it (match svn usernames to the issue tracker's login,) send emails, etc..
>
> The submitter would simply flip a bit-field on the ticket, the ticket software does all the setup work, the submitter submits the code to the branch, and when done, flips a status flag in the ticket tracker to indicate that the code is ready to be looked at. This has the benefit for forcing folks to go through the ticket system before delivering code.
>
>
> So yeah, it's definitely not a subversion thing. It's a bug/ticket/issue/workflow application thing.

Well, the fact that this can be implemented in a third-party or a
wrapper doesn't mean it should. Maybe it should in the first place (like
it happened with the svnmerge contrib wrapper tool) but I see some
advantages in implementing it natively:

- If done in a third-party tool, only that tool could be used for
getting this workflow thing (and AFAIK there are a lot of them used
currently in the opensource ecosystem: Trac, Bugzilla, Mantis, and even
small bug tracking tools associated to many forges like SourceForge,
GoogleCode, etc.) and thus would prevent massive adoption.
- Giving a tool the power to create accounts upon anonymous intervention
could be considered a small security risk.

The only advantage I see is the force to use the bug tracking tool. Then
I'm wondering if this should be implemented in a library which then can
be supported by many bug tracking tools...

Regards,

        Andrés

-- 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-03 23:01:45 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.